On 06/21/2017 02:41 AM, Richard Earnshaw (lists) 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. > > Then make sure the caller does touch the 0xf1000 page. If it's > allocated that much stack it should be forced to do the probe and not > rely on all it's children having to do it because it can't be bothered. That needs to be mandated at the ABI level if it's going to happen. The threat model assumes that the caller adheres to the ABI, but was not necessarily compiled with -fstack-check.
I'm all for making the common path fast and letting the uncommon cases pay additional penalties. That mindset has driven the work-to-date. But I don't think I have the liberty to change existing ABIs to facilitate lower overhead approaches. But I think ARM does given it owns the ABI for aarch64 and I would happily exploit whatever guarantees we can derive from an updated ABI. So if you want the caller to touch the page, you need to amend the ABI. I'd think touching the lowest address of the alloca area and outgoing args, if large would be sufficient. jeff