On 07/14/2017 10:34 AM, Segher Boessenkool wrote: > On Thu, Jul 13, 2017 at 10:35:55PM -0600, Jeff Law wrote: >>>> There's -fstack-check and -fstack-clash-protection. I think with the >>>> direction we're going they are fundamentally incompatible because >>>> neither the compiler nor kernel do anything to guarantee enough stack is >>>> available after hitting the guard for -fstack-clash-protection. >>> >>> Hrm, I have to think about that. >> Even if the kernel implements the reserved page stuff mentioned earlier >> in the thread, I'm not sure when we'd be able to reliably depend on that >> capability (or even check for it). >> >> ISTM that -fstack-check continues to be Ada centric and we have a new >> option to deal with stack-clash protection and the two simply just >> aren't allowed to be enabled together. > > So this essentially means Ada programs cannot get stack clash protection > at all? And if -fstack-check is really only useful for Ada, we shouldn't > mix up that option with the stack clash thing. It's not a simple yes/no.
For Ada the model is that the entire application will be compiled with -fstack-check and that each function that allocates space probes 2-3 pages beyond their immediate need to ensure space to run the signal handler (damn the large register files :-) Those are absolutely critical to keep in mind. In combination they allow prologues to skip the first 2-3 page probes (they were done earlier in the call chain). So from a standpoint of probing each and every allocated page, Ada with -fstack-check will do that if and only if every function is compiled with -fstack-check. But the actual allocation/probing tends to look like this in the prologues allocate all the stack space probe third page probe fourth page probe fifth page etc So there's a race condition between the allocation point and when the probes execute which means an async signal handler could be running on a clashed stack/heap. So an Ada program fully compiled with -fstack-check will mostly be protected from a stack-clash style attack. They could achieve better protection by fixing the -fstack-check=specific prologue sequences so that they allocate and probe a page at a time. That (mostly) closes the issue with signal handlers running on a clashed stack/heap. They could achieve a level of protection in mixed code environments by not skipping page probes. But that would result in significantly worse code given the current implementation of -fstack-check. > > With what is in trunk so far, yeah ;-) In principle the "set up a stack > frame" part of the prologue can be made a separate shrink-wrapping > component and then we'd have to worry. But it would be complicated to > do that and there is no real benefit I see so far, so it won't happen. > Nothing for you to have to worry about in any case :-) That's consistent with my thoughts as well. You could separately wrap the allocation, but it's not likely to be that beneficial and it would seem to add a fair amount of complexity. jeff
