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

[Jeff Law <law at redhat dot com>]

On 06/22/2017 10:07 AM, Szabolcs Nagy wrote:
> On 22/06/17 16:30, Jeff Law wrote:
>> It just happens to be the case that x86 hits *sp when it stores the
>> return pointer and that ppc always stores the backchain into *sp when it
>> allocates additional stack space.  As a result on those targets we know
>> the offset between the stack pointer and the most recent probe is zero
>> at the start of the callee's prologue.  That allows us to avoid the vast
>> majority of explicit probes.
>>
>> aarch64's ABI and ISA don't provide us with any such guarantees and we
>> have to make very conservative assumptions which leads to much more
>> explicit probing.
> 
> i think the aarch64 abi does not disallow access by the caller
> to *sp so i don't see the problem.
> 
> the caller can give various guarantees about how far back the
> last stack access was relative to the sp at entry to a function,
> but this does not have to be abi! the abi is not a hard guarantee
> anyway, asm code can always do tricks that is not abi clean but
> happens to work in practice, so in that sense relying on *sp
> 'was written' is incorrect assumption even on ppc/x86, in fact it
> would not work with the llvm 'safe stack' runtime as a probe,
> the stack clash would happen on the un-safe stack in that case
> not where the return address is stored.
Even assembly code needs to follow the ABI.  The ABI is the contract
that must be maintained at function call boundaries.

I'll have to look at llvm's safe stack again to see if/how that might
impact the assumptions we're making.

Jeff