On 28/10/17 05:08, Jeff Law wrote: > On 10/13/2017 02:26 PM, Wilco Dijkstra wrote: >> For larger frames the first oddity is that there are now 2 separate params >> controlling how probes are generated: >> >> stack-clash-protection-guard-size (default 12, but set to 16 on AArch64) >> stack-clash-protection-probe-interval (default 12) >> >> I don't see how this makes sense. These values are closely related, so if >> one is different from the other, probing becomes ineffective/incorrect. >> For example we generate code that trivially bypasses the guard despite >> all the probing: > My hope would be that we simply don't ever use the params. They were > done as much for *you* to experiment with as anything. I'd happy just > delete them as there's essentially no guard rails to ensure their values > are sane.
so is there a consensus now that 64k guard size is what gcc stack probing will assume? if so i can propose a patch to glibc to actually have that much guard by default in threads.. (i think it makes sense on all 64bit targets to have bigger guard and a consensus here would help making that change) >> Also on AArch64 --param=stack-clash-protection-probe-interval=16 causes >> crashes due to the offsets used in the probes - we don't need large offsets >> as we want to probe close to the bottom of the stack. > Not a surprise. While I tried to handle larger intervals, I certainly > didn't test them. Given the ISA I wouldn't expect an interval > 12 to > be useful or necessarily even work correctly. it's not clear what makes probing at every 64k hard, i think this should be clarified before we stick to this design. (..or before backporting such patches)
