Mail Archives: djgpp-workers/1999/08/22/06:45:08
On Sun, 22 Aug 1999, Martin Str|mberg wrote:
> Hans-Bernhard said:
>
> > Same problem as with the guard page approach: if the stack is overflown,
> > if will often happen in one large step, without touching all addresses in
> > between. Think of someone using a double a[200000]; local variable.
> > Stack corruption happens, but your guard value will only be hit if
> > that array is actually modified.
>
> I'm aware of that, but this one is very cheap to implement. And it
> will catch too deep function nesting, I think.
I don't think so. Most stack overflows are from declarations like
Hans-Bernhard mentioned: "double a[200000];". These are compiled into a
single instruction that decrements ESP. Your sugestion will only work if
the exact location where you put the special value is written to by the
code *before* it writes into lower addresses. If the code only reads from
the array, or writes to other array elements, it won't be caught.
For example, the following snippet is a clear disaster, but it won't be
caught by your suggestion:
int foo (int bar)
{
double a[200000];
a[0] = bar * M_PI;
printf ("%f\n", a[0]);
}
> Does anybody know why cc1 or whatever programs must have a larger
> stack?
Probably because GCC uses alloca a lot. But I didn't look close enough
to say for sure.
> It surely isn't because it declares huge arrays locally without
> trying to use them, right?
The problem is that the damage (and the crash) can happen before the code
accesses the allocated array. See the snippet above: the damage happens
in printf, whether or not the code accesses a[] after the call to printf.
> By the way, what data is first overwritten by a stack overrun?
The data in .bss section.
The memory of a DJGPP program is organized like this (in ascending order
of the linear addresses): .code, .data, .bss, stack, heap.
- Raw text -