bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] Re: alloca


From: Paul Eggert
Subject: Re: [Bug-gnulib] Re: alloca
Date: 13 Nov 2003 10:47:33 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Bruno Haible <address@hidden> writes:

> James Youngman wrote:
> > In the specific case of Linux, you should be able to get around the
> > problem by ensuring that you fill your arrays backwards.
> 
> This is a myth.

Is it really a myth?

What I think you're saying is that, if the alloca can be satisfied,
then it doesn't help to fill the arrays backwards.  This is correct,
at least by my quick reading of /usr/include/linux/mm.h's
expand_stack.  But the issue here isn't valid alloca calls; it's the
invalid ones with huge sizes (e.g. alloca (SIZE_MAX)).  For such
calls, if you merely access a few bytes at the start of the newly
"allocated" array (the base of which actually points into some other
storage, used for some other purpose), you may not have a page fault
at all, so expand_stack won't be called: but you'll still trash your
program.  However, if you adopt the approach Youngman suggests, you'll
eventually get a page fault due to a stack address that, if allocated,
would cause the program to exceed RLIMIT_STACK or RLIMIT_AS limits, so
the program will fail reliably.

It seems to me that the crucial issue here is the size of the
unwriteable barrier just past the stack.  If the operating system
guarantees that this barrier is always at least 8 KiB, for example,
then any alloca of 8 KiB or less is "safe", in the sense that stack
overflow will be detected reliably.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]