On 06/20/2017 05:22 PM, Wilco Dijkstra wrote: > Jeff Law wrote: >> But the stack pointer might have already been advanced into the guard >> page by the caller. For the sake of argument assume the guard page is >> 0xf1000 and assume that our stack pointer at entry is 0xf1010 and that >> the caller hasn't touched the 0xf1000 page. >> >> If FrameSize >= 32, then the stores are going to hit the 0xf0000 page >> rather than the 0xf1000 page. That's jumping the guard. Thus we have >> to emit a probe prior to this stack allocation. > > That's an incorrect ABI that allows adjusting the frame by 4080+32! A correct > one might allow say 1024 bytes for outgoing arguments. That means when > you call a function, there is still guard-page-size - 1024 bytes left that > you can > use to allocate locals. With a 4K guard page that allows leaf functions up to > 3KB, > and depending on the frame locals of 2-3KB plus up to 1024 bytes of outgoing > arguments without inserting any probes beyond the normal frame stores. > > This design means almost no functions need additional probes. Assuming we're > also increasing the guard page size to 64KB, it's cheap even for large > functions. I'm a little confused. I'm not defining or changing the ABI. I'm working within my understanding of the existing aarch64 ABI used on linux systems. My understanding after reading that ABI and the prologue code for aarch64 is there's nothing that can currently be relied upon in terms of the offset from the incoming stack pointer to the most recent "probe" in the caller.
Just limiting the size of the outgoing arguments is not sufficient though. You still have the dynamic allocation area in the caller. The threat model assumes the caller follows the ABI, but does not have to have been compiled with -fstack-check. Thus you'd have to have an ABI mandated probe at the lowest address of the dynamic allocation area and limit the size of the outgoing stack arguments for your suggestion to be useful. If ARM wants to update the ABI, that's fine with me. But until that happens and compilers which implement that ABI are ubiquitous ISTM we can't actually depend on those guarantees. If I'm wrong and there is some guarantee we can rely on, let me know. It's trivial to change the initial state to utilize such guarantees. jeff
