Re: OS stopping stack buffer overflow exploits

From: yoann@mandrakesoft.com
Date: Sun Jun 04 2000 - 09:43:02 EST


"Peter T. Breuer" <ptb@it.uc3m.es> writes:

> "A month of sundays ago yoann@mandrakesoft.com wrote:"
> > "Peter T. Breuer" <ptb@it.uc3m.es> writes:
> > > 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.
> >
> > GCC use lexical scoping for nested function, lexical scoping use
> > trampolines... so it will break...
>
> This is goobledegook. Lexical scoping is precisely what I was referring
> to by "a question of namespaces and syntactic scoping". It's a parsing
> detail, or a compiler detail, _not_ an implementation strategy. There
> is no more need to invoke a special implementation strategy for nested
> functions than there is to invoke one for nested blocks.

right, but having to remake the nested function implementation is not
a good idea, especially to implement stuff like non executable stack.

( Read the 'Proposal LUID' thread )

>
> > [snip]
> > GNU CC implements taking the address of a nested function using a
> > technique called "trampolines". A paper describing them is available
> > as `http://master.debian.org/~karlheg/Usenix88-lexic.pdf'
> > [snip]
>
> Thanks. Looked at it once, and it was incomprehensible then. Glad
> to say I've forgotten it entirely since. Do they have an ascii version?
>
> Interestingly, I get a 404 from the address you give above. The
> homepage surrounding it says:
>

sorry, it was just a snapshot of the gcc info page,
the interesting stuff in it was above the url.

-- 
		-- Yoann http://www.mandrakesoft.com/~yoann/
 It is well known that M$ product don't make a free() after a malloc(),
the unix community wish them good luck for their future developement.

- 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/



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