Re: VLA and alloca

[Pádraig Brady]

On 14/01/19 17:57, Bruno Haible wrote:
> Hi,
> 
> Pádraig Brady wrote:
>>> In function 'dcpgettext_expr':
>>> /home/james/source/GNU/findutils/git/gnu/findutils/gl/lib/gettext.h:216:
>>> warning: variable length array 'msg_ctxt_id' is used
>>
>>> In other words, "gcc -Wvla" is issuing a warning for a construct we
>>> know is safe.   However, I can't be sure I won't accidentally write
>>> code in the future which is not protected by something similar to
>>> _LIBGETTEXT_HAVE_VARIABLE_SIZE_ARRAYS.   So I think that -Wvla is a
>>> useful warning flag.
>>>
>>> Is there a way of eliminating this false positive which doesn't force
>>> me to give up -Wvla?   I mean, apart from giving up the use of VLAs in
>>> gnulib even when it's safe to use them.
>>
>> We might want to disable use of VLAs even if the compiler supports it,
>> for security reasons (like the Linux kernel now does)
> 
> The proposed patch looks reasonable to me. And it would be useful to
> add a bit of documentation, namely: Who should define GNULIB_NO_VLA,
> and for what reasons?
> 
> There are two related issues:
> 
> * GCC not only has a warning -Wvla (whose purpose is probably to avoid
>   VLAs in order to produce code compatible with other compilers), but
>   also -Wvla-larger-than=N [1], whose purpose is that the stack "jumps"
>   by not more than one page at once.
> 
> * It also has a warning -Walloca-larger-than=N [1], with the same purpose.
> 
> Maybe we can come to a gnulib-wide policy regarding the use of alloca()
> and VLAs?


Indeed alloca has similar considerations.
Though there is the alloca module to handle portability,
and use of alloca is explicit and so easier to audit/manage etc.
VLAs are tricky as they can be introduced if the array size
is not determined to be constant, which may happen inadvertently.
Also the portability concerns are more awkward.

I've pushed this with some comments at the current single GNULIB_NO_VLA usage.

> Does glibc have such a policy?
> 
> My thoughts regarding these options are mixed:
> 
> * On one hand, we are regularly using machines where a process may have
>   more than 1 million of memory pages. A policy that forbids stack allocations
>   of more than 1 page has the effect that the stack will rarely grow beyond
>   200 memory pages. The resulting pressure to use heap allocations instead
>   of stack allocations may be justified for multi-thread applications, but
>   is not justified for single-thread applications, which could otherwise
>   use 200000 memory pages of stack without problems.
> 
> * On the other hand, there is the problem of detecting a stack that "jumps".
>   There are mitigations in the Linux kernel [2][3], as well as in GCC:
>   GCC has an option -fstack-clash-protection [4].
> 
> What are the widely accepted points of view on these topics?

I've not analyzed the security concerns in detail, but in general
large allocations on the stack are bad for security and somewhat for 
performance,
so I think it's useful for programs to be able disable alloca and VLAs,
but independently from each other.

cheers,
Pádraig.