Re: Probe emission in fstack-clash-protection

[Florian Weimer <fweimer@redhat.com>]

* Varun Kumar E. via Gcc:

> Hello,
>
> https://godbolt.org/z/P3M8s8jqh
> The above case shows that gcc first decreases the stack pointer and then
> probes.
>
> As mentioned by Jeff Law (reference
> <https://developers.redhat.com/blog/2019/04/30/stack-clash-mitigation-in-gcc-why-fstack-check-is-not-the-answer#>)
> under "More issues with -fstack-check". If an asynchronous signal is
> received between the decrement of stack pointer and probing of the pages.
> *"In that case, the stack pointer could be pointing beyond the guard into
> the heap. The signal arrives and the kernel transfers control to the
> registered signal handler. That signal handler is then running while its
> stack is pointing into the heap. Thus, the attacker has clashed the stack
> and heap, and there's a reasonable chance they can gain control over the
> program" *
>
> So, Shouldn't we first probe and if successful only then update the stack
> pointer? Or Maybe I have understood it incorrectly.

Let me rephrase a bit.  The caller has asserted that (%rsp) is valid
upon entry to the function because that's where the return address is
stored.  That means that (%rsp - 4096) is still in the guard page, so
the subsequent probe works.  But the kernel fault handler will not write
to that location because it has to protect the return address and the
red zone, so the first location used is (%rsp - 4096 - 8 - 128) or
thereabouts.

Jeff, this looks like a real bug to me.  It doesn't affect the main
thread on GNU/Linux because the kernel uses more than one page for the
guard area.  However, glibc uses exactly one page.  We could change that
to two pages on x86-64 at least without ill effects, I believe.  Or fix
GCC's probing to account for the red zone.

Thanks,
Florian