Hi! On Mon, Jan 14, 2019 at 12:24:43PM +0000, Matthew Malcomson wrote: > I've found a testcase where the stack protector code generated through > `-fstack-protector-all` doesn't actually protect anything.
[ snip ] > When compiling on aarch64 with > ~gcc -fstack-protector-all -g -S stack-reorder.c -o test.s -O3 > In this snippet the stack protect set and test patterns are right next to each > other, causing the stack protector to essentially do nothing. > The RTL insns to set the two elements in `buf[]` are left after this snippet. I see it the other way around: the two stores to buf are done before writing the canary. This is wrong. Please open a PR? See https://gcc.gnu.org/bugs.html . > The stack_protect_set and stack_protect_test patterns are put together in the > sched1 pass (as seen by the change in the RTL between the previous dump and > that one). > > I would like to know what is supposed to stop RTL from the stack_protect_set > pattern from being reordered around the code it protects like this? Good question. aarch64 isn't doing anything special here afais. > Could the reasoning be that for those patterns likely to cause a security risk > the rescheduling is stopped by jumps/labels/calls? No, just the memory accesses should already not be reordered. Segher
