Re: alloca and reliable stack-overflow detection in glibc functions

[Paul Eggert <eggert at CS dot UCLA dot EDU>]

Roland McGrath <roland@redhat.com> writes:

> glibc does not support arbitrarily small stack sizes.

OK, but I'm not worried about that.  I'm worried about small
stack-barrier sizes.

Here's another way to put it.  Currently, as I understand it,
setenv() with large arguments can do one of the following:

  1.  Succeed.
  2.  Return -1 (due to heap exhaustion).
  3.  Generate a signal (due to caught stack overflow).
  4.  Silently corrupt storage (due to uncaught stack overflow
        after a large alloca()).

I don't want (4) to happen, as it's real nasty (e.g., security holes).

Can I rule out (4) within glibc by arranging for the stack to have at
least __MAX_ALLOCA_CUTOFF bytes of inaccessible stack-barrier address
space just past the allocated stack end?  I had thought that was the
partly the goal of __MAX_ALLOCA_CUTOFF, but perhaps I'm wrong.

If not, is there some other way to rule out (4) within glibc?