Date: Wed, 30 Aug 1995 22:58:26 +0300 From: System daemons <daemon@crocodil.monolit.kiev.ua> Message-ID: <199508301958.WAA09655@crocodil.monolit.kiev.ua>
next in thread | raw e-mail | index | archive | help
David Greenman (davidg@Root.COM) wrote: > >> the segment descriptors support the text (code) vs data > >> identification. this would be a big win regarding security (and writing > >> to wild pointers that hit your own code segment ;) unfortunately, we haven't code and data pointers in current addressing model (umm, sounds like dos-ish/window-ish/PM-ish segments again... never mind.) > >I don't think I have ever seen a program execute anything in the datasegment, > >so we should have little trouble with this... Think of threaded code interpreters which create code on the fly, then execute it. I bet at least several Lisp, Scheme, ML, or Forth systems do it actually. > Umm, and how are you going to deal with shared libraries or other mapped > files that you wish to execute? The best you could hope for would be to limit > the code segment to below the stack (to prevent execution of stuff on the > stack), but I don't think this would affect the recent syslog problem - wasn't > the stack buffer allocated from the data segment? Do you know about `trampolines' which recent versions of gcc uses to call nested functions? The problem with this stuff is, when you have bar() defined _inside_ foo(), and want to pass &bar outside of foo(), (e.g. to qsort() which could call bar() by pointer), you want bar() to be able to access all local variables which foo() have at time of its recent invocation. Since the address of foo()'s stack frame isn't known at compile time, gcc solves this by creating a `trampoline', i.e. a small piece of code which loads some CPU register with (current) address of foo()'s locals, then invokes bar(). This small piece of code is created on the stack, and its address is passed to external functions as address of bar(). Neat, isn't it? But this also means that stack pages should be made executable. Dmitry (w/language implementation hat on ;-) )
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508301958.WAA09655>