«

Hello:

We know that C programs are often vulnerable to buffer overflows which
overwrite the stack.

But my question is: Why does C insist on storing local variables on the
stack in the first place?

I can see two definite disadvantages with this:
1) deeply nested recursive calls to a function (especially if it defines
large local arrays) can easily overflow the stack
2) the problems described above of security vulnerabilities.

My solution would be for C instead to store its local variables on the
heap - effectively separating data from executable code.

What do people think?

On Fri, 14 Mar 2008 21:58:57 +0100, CJ wrote:
> Hello:
>
> We know that C programs are often vulnerable to buffer overflows which
> overwrite the stack.
>
> But my question is: Why does C insist on storing local variables on the
> stack in the first place?

It doesn't.

CJ wrote, On 14/03/08 20:58:
> Hello:
>
> We know that C programs are often vulnerable to buffer overflows which
> overwrite the stack.

Only on implementations which use the stack, although this is probably
the majority. On implementations that don't use a stack such erroneous
programs overwrite something else instead.

> But my question is: Why does C insist on storing local variables on the
> stack in the first place?

Because that is one of the things the chip designers provide the stack for.

> I can see two definite disadvantages with this:
> 1) deeply nested recursive calls to a function (especially if it defines
> large local arrays) can easily overflow the stack

If some other resource is used then that resource can be easily
exhausted as well.

> 2) the problems described above of security vulnerabilities.
>
> My solution would be for C instead to store its local variables on the
> heap - effectively separating data from executable code.
>
> What do people think?

On most implementations with a stack and a heap your suggestion would be
very inefficient.

A better solution would be for the chip designers and manufactures to
provide separate stacks for return addresses and data with the stack for
return addresses being protected.
--
Flash Gordon

CJ wrote:
) But my question is: Why does C insist on storing local variables on the
) stack in the first place?

It doesn't. Your question is moot.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Harald van Dijk wrote:
> On Fri, 14 Mar 2008 21:58:57 +0100, CJ wrote:
>> Hello:
>>
>> We know that C programs are often vulnerable to buffer overflows which
>> overwrite the stack.
>>
>> But my question is: Why does C insist on storing local variables on the
>> stack in the first place?
>
> It doesn't.

This is blatantly wrong. Most C implementations use the stack.

This is just nonsense, from the regular regulars...

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

CJ wrote:

> Hello:
>
> We know that C programs are often vulnerable to buffer overflows which
> overwrite the stack.
>
> But my question is: Why does C insist on storing local variables on
> the stack in the first place?

It doesn't A hardware stack isn't necessary to implement C as defined by
it's standard. It just makes sense in a whole lot of systems where
there is native stack support. It's also easier on the compiler.

> I can see two definite disadvantages with this:
> 1) deeply nested recursive calls to a function (especially if it
> defines large local arrays) can easily overflow the stack
> 2) the problems described above of security vulnerabilities.
>
> My solution would be for C instead to store its local variables on the
> heap - effectively separating data from executable code.
>
> What do people think?

All computing resources are finite. The problem is not running out of
resources (which can always happen and for which there is no possible
solution), but in protecting programs from each other, so that a faulty
program, or module can at most destroy itself.

WRT what you say above, no, on system that support maintaining a
hardware stack, there is absolutely no sense in not using it,
particularly for languages like C and C++. The memory protection
enabled by the system will have equal effect, whether it's the stack or
the heap that is involved in overflow. Not using the hardware support
for stacks would impact performance considerably.

It would also complicate compilers that will have to maintain a software
stack anyway for implementing automatic objects.

The whole scheme gives up a lot for almost no real gain. Not in C.

Willem wrote:
> CJ wrote:
> ) But my question is: Why does C insist on storing local variables on the
> ) stack in the first place?
>
> It doesn't. Your question is moot.
>
>
> SaSW, Willem

This is wrong. Most C implementations use the hardware stack

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> Harald van Dijk wrote:
>> On Fri, 14 Mar 2008 21:58:57 +0100, CJ wrote:
>>> Hello:
>>>
>>> We know that C programs are often vulnerable to buffer overflows which
>>> overwrite the stack.
>>>
>>> But my question is: Why does C insist on storing local variables on the
>>> stack in the first place?
>>
>> It doesn't.
>
> This is blatantly wrong. Most C implementations use the stack.
>
The question was "Why does C *insist* on storing local variables on the
stack in the first place?"

It doesn't. If it does, show us the relevant section in the standard.

The fact that most implementation do use a stack, doesn't make it a
requirement.

--
Ian Collins.

CJ wrote:
> Hello:
>
> We know that C programs are often vulnerable to buffer overflows which
> overwrite the stack.
>

Only if you can execute code in the stack

> But my question is: Why does C insist on storing local variables on the
> stack in the first place?
>

The principal reason is efficiency. Stack allocation is very fast,
in most cases just a single machine instruction. Deallocation is equally
fast, with a single instruction.


> I can see two definite disadvantages with this:
> 1) deeply nested recursive calls to a function (especially if it defines
> large local arrays) can easily overflow the stack

Yes, that is why stack allocation of large arrays is not a very
good idea.

> 2) the problems described above of security vulnerabilities.
>

This happens only if you have the buffer overflow in the first place.

Note that a buffer overflow of a heap allocated buffer is very
bad also.

> My solution would be for C instead to store its local variables on the
> heap - effectively separating data from executable code.
>

Yes, that is "a" solution. You can implement this easily in C
if you just instead of

int fn(void)
{
char buffer[BUFSIZ];

}

you write

int fn(void)
{
char *buffer = malloc(BUFSIZ);
}

> What do people think?
>

I think that you should allocate variables as you think is the best for
your application.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> Willem wrote:
>> CJ wrote:
>> ) But my question is: Why does C insist on storing local variables on the
>> ) stack in the first place?
>>
>> It doesn't. Your question is moot.
>>
>>
>> SaSW, Willem
>
> This is wrong. Most C implementations use the hardware stack
>
Please stop confusing practical implementation with requirements.

--
Ian Collins.