On Tue, Jul 11, 2017 at 08:02:26PM -0600, Jeff Law wrote: > On 07/11/2017 06:20 PM, Wilco Dijkstra wrote: > > Jeff Law wrote: > >> aarch64 is the first target that does not have any implicit probes in > >> the caller. Thus at prologue entry it must make conservative > >> assumptions about the offset of the most recent probed address relative > >> to the stack pointer. > > > > No - like I mentioned before that's not correct nor acceptable as it would > > imply > > that ~70% of functions need a probe at entry. I did a quick run across SPEC > > and > > found the outgoing argument size is > 1024 in just 9 functions out of > > 147000! > > Those 9 were odd special cases due to auto generated code to interface > > between > > C and Fortran. This is extremely unlikely to occur anywhere else. So even > > assuming > > an unchecked caller, large outgoing arguments are simply not a realistic > > threat. > Whether or not such frames exist in SPEC isn't the question. THere's > nothing in the ABI or ISA that allows us to avoid those probes without > compromising security. > > Mixed code scenarios are going to be a fact of life, probably forever > unless we can convince every ISV providing software that works on top of > RHEL/*BSD/whatever to turn on probing (based on my experiences, that > has exactly a zero chance of occurring).
On the other hand if probing is fast enough that it can be on by default in gcc there should be much less of it. Even if you did change the ABI to require probing it seems unlikely that code violating that requirement would hit problems other than this security concern, so I'd expect there will be some non compliant asm out there. > In a mixed code scenario a caller may have a large alloca or large > outgoing argument area that pushes the stack pointer into the guard page > without actually accessing the guard page. That requires a callee which > is compiled with stack checking to make worst case assumptions at > function entry to protect itself as much as possible from these attacks. It seems to me pretty important to ask how many programs out there have a caller that can push the stack into the guard page, but not past it. I'd expect that's not the case for most allocas, either they are safe, or can increase the stack arbitrarily. I'd expect its more likely with outgoing arg or large buffer allocations though. I think the largest buffer Qualys found was less than 400k? So 1 256k guard page should protect 95% of functions, and 1m or 2m seems like enough to protect against all non malicious programs. I'm not sure, but this is a 64 bit arch, so it seems like we should have the adress space for large guard pages like that. There's also the trade off that increasing the amount of code that probes reduces the set of code that can either move the stack into or past the guard page. > THe aarch64 maintainers can certain nix what I've done or modify it in > ways that suit them. That is their choice as port maintainers. > However, Red Hat will have to evaluate the cost of reducing security for > our customer base against the performance improvement of such changes. > As I've said before, I do not know where that decision would fall. > > > > > > Therefore even when using a tiny 4K probe size we can safely adjust SP by > > 3KB > > before needing an explicit probe - now only 0.6% of functions need a probe. > > If we choose a proper minimum probe distance, say 64KB, explicit probes are > > basically non-existent (just 35 functions, or ~0.02% of all functions are > > > 64KB). > > Clearly inserting probes can be the default as the impact on code quality > > is negligible. > Again, there's nothing that says 3k is safe. You're picking an > arbitrary point that is safe in a codebase you've looked at. But I'm > looking at this from a "what guarantees do I have from an ABI or ISA > standpoint". The former may be more performant, but it's inherently > less secure than the latter. On the other hand making -fstack-check=clash the default seems to me like a very significant security improvement. Trev
