On Mon, Jun 19, 2017 at 05:50:56PM +0000, Joseph Myers wrote:
> On Mon, 19 Jun 2017, Jeff Law wrote:
>
> > A key point to remember is that you can never have an allocation
> > (potentially using more than one allocation site) which is larger than a
> > page without probing the page.
>
> There's a platform ABI issue here. At least some kernel fixes for these
> stack issues, as I understand it, increase the size of the stack guard to
> more than a single page. It would be possible to define the ABI to
> require such a larger guard for protection and so reduce the number of
> (non-alloca/VLA-using) functions that need probes generated, depending on
> whether a goal is to achieve security on kernels without such a fix.
> (Thinking in terms of how to get to enabling such probes by default.)
Note that the kernel imposed stack guard page is just one thing (eventhough
probably the most common), POSIX threads allow to specify the guard size
for stack sizes too and increasing the guard size too much in that case is a
bigger problem than just doing it for a single initial thread.
Also, people can override it, if they use 0 guard size, we can say it is
their problem to allow this kind of exploits, but asking them to use much
larger guard sizes might be a problem for apps that create many threads.
Jakub
