This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: alloca avoidance patches
On 06/19/2017 12:00 PM, Szabolcs Nagy wrote:
> On 19/06/17 18:58, Joseph Myers wrote:
>> On Mon, 19 Jun 2017, Szabolcs Nagy wrote:
>>
>>> in any case i think it's more productive to
>>> fix the stack usage bugs, instead of hardening
>>> for this class of exploitable stack usage bugs,
>>> even if the guard page catches the issue it
>>> is an unwanted crash.
>>
>> Which gets back to wanting to use appropriate warning options, even if
>> they don't catch all cases - and to needing an ABI-defined size it's safe
>> to allocate, possibly more than a page if you rely on kernel fixes.
>>
>> (I expect strtold has one of the larger static stack allocations in glibc.
>> I can see such amounts, possibly more, being needed for fixing cpow{,f,l}
>> inaccuracy as well, on the assumption we should avoid libm functions
>> calling malloc.)
>>
>
> i know at least crypt call in glibc can allocate 128K on the
> stack, so glibc has bigger problems than strtold
It's useful to separate out how the allocations occur.
Statically allocated space is allocated and probed by the prologue.
There's just over 2 dozen of these on x86 which allocate a page or more
within glibc. These are trivially found by disassembly or other tooling
that just looks at large constant allocations. You'll find workers for
strtold, realpath, printf, tmpfile, tempnam, strxfrm, wcstold, wcsxfrm,
fnmatch, fnwmatch, getwd and others.
Dynamically allocated pages (eg alloca/vlas) are allocated and probed by
more generic code. The key difference is these (and their sizes) are
not trivially discovered by just reading the assembly code. You
actually have to walk through the code which does rounding, alignment,
etc for dynamic stack space. There's actually a lot more of these and I
believe the crypt code you're referring to falls into this class.
Protecting the former requires a lot more work in GCC than protecting
the latter as the former requires target specific improvements while the
latter is more generic code that runs long before prologue/epilogue
generation.
jeff