From owner-freebsd-hackers Sat Jan 25 12:45:54 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60C3637B401 for ; Sat, 25 Jan 2003 12:45:53 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE43A43EB2 for ; Sat, 25 Jan 2003 12:45:52 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id h0PKjk4a029054; Sat, 25 Jan 2003 15:45:46 -0500 (EST) Date: Sat, 25 Jan 2003 15:45:46 -0500 (EST) From: Daniel Eischen To: "=?iso-8859-1?q?Pedro=20F.=20Giffuni?=" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: idea from NetBSD: signal trampoline on libc ? In-Reply-To: <20030125190021.80728.qmail@web13402.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 25 Jan 2003, [iso-8859-1] Pedro F. Giffuni wrote: > Hi; > > I was reading an interview about IRIX binary > compatibility on NetBSD, and it looks like they > learned a few tricks. > > This article gets into their native implementation of > signals: > > http://www.onlamp.com/pub/a/bsd/2002/10/10/irix.html > > At the end of the article Emmanuel Dreyfus mentions: > > "One other interesting thing to note is that since > that code was written, Jason Thorpe implemented signal > trampolines provided by libc for NetBSD native > processes, thus adopting the same scheme IRIX used. > The libc provided signal trampoline was adopted in > NetBSD because it removes the need to execute code on > the stack. Memory pages mapped on the stack can > therefore be made non executable (the Memory > Management Unit of all modern CPU are able to enforce > such rules), and we are able to fix a whole class of > security problems. With a non executable stack, it is > not possible anymore to exploit a buffer overflow on a > local variable by executing some user-supplied code > stored on the stack." I think Jake already did this for sparc64, and Jon Mini was working on doing it for i386. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message