Re: RFC: stack/heap collision vulnerability and mitigation with GCC

[Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>]

Jeff Law wrote:
> You can be in one of 3 states when you start the callee's prologue.
>
> 1. You're somewhere in the normal stack.
>
> 2. You've past the guard and are already in the heap or elsewhere
>
> 3. You're somewhere in the guard
>
> State #3 is what we're trying to address.  The attacker has advanced the
> stack pointer into the guard, but has not fully breached the guard.  We
> need to ensure that we hit the guard to prevent the breach.

State 3 is only interesting if all code has been built with probing enabled. In that
case we'd define how far the caller may have gone into the guard band and the
callee will probe exactly when needed, so it's guaranteed to prevent a breach.

If the caller hasn't enabled probing and does alloca, you're simply dead already.
All an attacker needs to do is to increase the alloca size to complete the breach.

If a full breach isn't feasible in a caller (ie. no alloca) then it can only go a tiny
amount into the guard band since the outgoing argument size is tiny. If the callee
has probing enabled and uses a reasonable maximum outgoing argument size
(say more than the maximum across a whole distro), the chances you could breach
the stack guard are infinitesimal.

So I still don't understand what exactly is so much worse on AArch64.

Wilco