From owner-freebsd-security Wed Aug 30 13:06:04 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id NAA27493 for security-outgoing; Wed, 30 Aug 1995 13:06:04 -0700 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id NAA27481 for ; Wed, 30 Aug 1995 13:05:46 -0700 Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQzfbk19811; Wed, 30 Aug 1995 16:05:16 -0400 Received: from uanet.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Wed, 30 Aug 1995 16:05:32 -0400 Received: by crocodil.monolit.kiev.ua (8.6.8.1/8.5) id WAA09655 for security@freebsd.org; Wed, 30 Aug 1995 22:58:26 +0300 Date: Wed, 30 Aug 1995 22:58:26 +0300 From: System daemons Message-Id: <199508301958.WAA09655@crocodil.monolit.kiev.ua> Apparently-To: security@freebsd.org Sender: security-owner@freebsd.org Precedence: bulk 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 ;-) )