This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08
Jeff Law wrote:
> On 07/17/2017 05:27 AM, Wilco Dijkstra wrote:
> > A minimum guard size of 64KB seems reasonable even on systems with
> > 4KB pages. However whatever the chosen guard size, you cannot defend
> > against hostile code. An OS can of course increase the guard size well
> > beyond the minimum required, but that's simply reducing the probability -
> > it is never going to block a big unchecked alloca.
> That's a kernel issue and I'm not in a position to change that. On
> systems with a 64bit address space, I'm keen to see the kernel team
> increase the guard size, but it's not something I can unilaterally make
> happen.
Well if we want the stack guard catch cases with high probability even if some
or most of the code is unchecked, it must be made much larger. And the fact
you can set the stack guard to zero in GLIBC is worrying as that would allow an
attacker to trivially bypass the stack guard...
> > Outgoing args are not an area for concern even with a 4KB stack guard.
> They are a concern and as the size of the guard comes down, they become
> an increasing concern, IMHO.
At 4KB it's 1000 times more likely to have a frame that could skip the stack
guard than outgoing args. That's before we consider alloca which is even
more common.
> > In 99% of the frames only one stack allocation is made. There are a few
> > cases where the stack can be adjusted twice.
> BUt we still have to deal with the cases where there are multiple
> adjustments. Punting in the case of multiple adjustments isn't the
> right thing to do. Some level of tracking is needed.
I didn't say we should punt, just that no tracking is required. The AArch64 prolog
code is extremely simple. The only adjustments that need to be checked are
initial_adjust and final_adjust. Callee_adjust doesn't need any checks since it is
limited by the range of STP (ie. < 512) and if the locals are large, it is zero.
Anyway the only complex case is shrinkwrapping. We know that at least LR must be
saved before a call, but with -fomit-frame-pointer it doesn't always end up at the
bottom of the callee-saves. We could take its offset into account or force it at offset 0.
> > To be safe I think we first need to probe and then allocate. Or are there going
> > to be extra checks in asynchronous interrupt handlers that check whether SP is
> > above the stack guard?
> That hits the red zone, which is unfortunate. But it's acceptable IMHO.
How do you mean? What will happen if SP points into the heap? Will the trap
handler just write to it without any check?
Wilco