Linux-kernel mailing list archive 2000-23,: Re: OS stopping stack buffer overflow exploits

# Re: OS stopping stack buffer overflow exploits

Khimenko Victor (khim@sch57.msk.ru)
Sun, 4 Jun 2000 20:56:13 +0400 (MSD)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Frederic Bouvier: "Re: Abit KA7 PCI problems? (Kx133 + es1371)"
- Previous message: Menaka Lashitha Bandara: "Rivafb in 2.3.40"
- Maybe in reply to: Robert Redelmeier: "OS stopping stack buffer overflow exploits"
- Next in thread: Xuan Baldauf: "Re: OS stopping stack buffer overflow exploits"

In <200006041256.OAA19637@oboe.it.uc3m.es> Peter T. Breuer (ptb@it.uc3m.es) wrote:
> "A month of sundays ago Florian Weimer wrote:"
>> "Peter T. Breuer" <ptb@it.uc3m.es> writes:
>> > "A month of sundays ago Florian Weimer wrote:"
>> > > The C and C++ frontends only generate trampolines if you use a GNU
>> > > extension (nested functions).
>> > And I have no idea why they should want to: nesting is purely a
>> > question of namespaces and syntactic scoping. It should impact
>> > the implementation semantics not at all.
>> Yes, that's right. That's why we need trampolines: otherwise, pointers
>> to nested functions would have semantics differing from ordinary function
>> pointers.

> Why so? When we do the call the return address gets pushed and we jump
> to the pointer. From then on the (nested) function execution is
> standard.

Not exactly.

> It references locations in its frame on the stack for its
> local variables, and locations higher up the stack for the enclosing
> functions variables.

Not always.

> The nested function isn't visible from anywhere else so

Here is point of mistake. BIG mistake. Yes, nested function itn't visible from
anywaye else. POINTER to that function visible from "anywhere else". And then
if yu have pointer to function you can call it, you know. The question is
"how" ?

> the enclosing functions frame must be above it on the stack
> and the compiler can generate the right relative offsets for them.

"enclosing functions frame" must be above it on the stack. Just not "directly
above" - it can be everywhere in the stack. It can be even "in the stack of
other thread".

> Where does a trampoline come into it?

Just where yuo missed all interesting parts :-)

-- Sample in standard pascal without GNU extension --
procedure for_each(_from,_to:integer;procedure _do(x:integer));
var
i:integer;
begin
for i:=_from to _to do
_do(i);
end;

procedure draw_table;
var
y:integer;
procedure one_step(x:integer);
begin
write(x*y:4);
end;
begin
for y:=1 to 10 do begin
for_each(1,10,one_step);
writeln;
end;
end;
begin
draw_table;
end.
-- cut --

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Frederic Bouvier: "Re: Abit KA7 PCI problems? (Kx133 + es1371)"
- Previous message: Menaka Lashitha Bandara: "Rivafb in 2.3.40"
- Maybe in reply to: Robert Redelmeier: "OS stopping stack buffer overflow exploits"
- Next in thread: Xuan Baldauf: "Re: OS stopping stack buffer overflow exploits"