Re: OS stopping stack buffer overflow exploits

From: Horst von Brand (
Date: Mon Jun 05 2000 - 10:51:47 EST

"Khimenko Victor" <> said:
> Horst von Brand ( wrote:


> HB> Take a look at a book on compiler building, where they discuss Algol-like
> HB> languages. There are two major ways of implementing globals (variables in
> HB> surrounding blocks):
> HB> - A static link in each activation record that points to the parent's
> HB> activation record. When accessing a global variable, you walk the static
> HB> links until reaching the correct stack frame. Here a function (pointer)
> HB> is passed as a static link value plus a pointer to the code to run. This
> HB> is slow, but simple.
> It's slow even for non-nested functions.

Yes, but access to global variables is rare. And a smart compiler would
cache the pointers to the activation records anyway.

> HB> - A display, i.e., an array of pointers to the active stack frames
> HB> for each level. The function is passed as a pointer to the code plus
> HB> its display (part of it, really; not all has to be replaced). This is
> HB> more efficient for global access, but hairy to implement (and
> HB> probably impossible with HB> separate compilation, which can create
> HB> displays of different depths in HB> different source files).

> And once again you can not do this without affection call of "normal"
> (non-nested) function.

This _is_ the normal (only!) case in these languages. A "function pointer"
in them isn't just a pointer to where the fuction starts. If everybody
agrees on that, there isn't any trouble. In C you have to interact with
code written by others and ABIs that specify that a function pointer is
just the plain address where the function starts. Can't retrofit Algol-like
nesting into that except by some trampoline trickery or something even more

Dr. Horst H. von Brand             
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:21 EST