This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question on scheduling of stack_protect_prologue
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Matthew Malcomson <Matthew dot Malcomson at arm dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Fri, 18 Jan 2019 17:49:46 -0600
- Subject: Re: Question on scheduling of stack_protect_prologue
- References: <0ba32bd1-50a6-d2dc-5a69-5df7409574d6@arm.com>
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