Re: alloca avoidance patches

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 19/06/17 22:37, Jeff Law wrote:
> 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.

i see, so target specific sp adjustments in prologue/epilogue
are hard to deal with in gcc, otherwise the protection is
simple and it should have small overhead in practice.

actually crypt does not have the issue i thought it had.
i remembered that struct crypt_data is big and i saw it being
allocated on the stack before, but it seems that was not in
glibc.. sorry for the noise. (otoh callers of crypt_r likely
have the issue of >128k stack use)