Re: [RFC] nptl: change default stack guard size of threads

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

On 12/12/17 19:30, Florian Weimer wrote:
> I'm a bit surprised that the 1K/3K split wouldn't achieve that (i.e., pushing the cost of probing into he
> noise).  Is this because GCC wasn't built for this and has no way to recognize implicit probes which occur

we don't know the exact overhead, the current
patch does not emit optimal probing sequences,
but >3K stack use is common.

> The patch which started this libc-alpha thread applied the 64 KiB gap size to 32-bit architectures as well. 
> This is the primary reason why I'm objecting strongly to it.

that glibc patch added an arch specific knob.

otoh i don't think we have different code on
the gcc side for ilp32 so it will use the
same probing interval in gcc-8.

> If aarch64 wants to do their own thing in 64-bit mode, I'm won't complain that much.

i can prepare a patch, but it will need to
change generic code in glibc.
(because a lot of stack accounting code
is broken or hard codes 1page guard)

> The existing ecosystem offers only one page size.  The larger main stack guard region size provided by the
> kernel was a stop-gap measure, initially with the intent to patch nothing else, but it did not work out that
> way.  I don't think 64 KiB would make a significant dent in terms of practical exploitability (all published
> exploits used larger frames or alloca-based frames anyway).
> 
> If GCC assumes more than one guard page, a lot of things need to change, and it is difficult to communicate
> under what conditions a binary has been properly hardened.  If this is the cost for enabling
> -fstack-clash-protection by default on aarch64, then so be it, but we should not make these changes on
> architectures where they do not bring any tangible benefit or actually hurt (due to address space consumption).

glibc can force >=64k guard, no matter what the
user setting is, but as i wrote in another mail
i don't think that's a good idea.