Re: VLA and alloca

[Bruno Haible]

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?

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?

Bruno

[1] https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Warning-Options.html
[2] https://lwn.net/Articles/725832/
[3] https://lwn.net/Articles/727703/
[4] https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Instrumentation-Options.html