From owner-freebsd-security@FreeBSD.ORG Fri Nov 4 00:23:51 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53BCE16A41F for ; Fri, 4 Nov 2005 00:23:51 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 103DC43D45 for ; Fri, 4 Nov 2005 00:23:50 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 03 Nov 2005 16:23:49 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <436AAA14.7020603@elischer.org> Date: Thu, 03 Nov 2005 16:23:48 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: martinko References: <200510270608.51571.db@traceroute.dk> <200510291242.16461.db@traceroute.dk> <20051029131519.GA22254@ada.devbox.be> <200510291412.57656.db@traceroute.dk> <86pspjz0xu.fsf@xps.des.no> <43690E40.5040705@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 04 Nov 2005 13:59:13 +0000 Cc: freebsd-security@freebsd.org Subject: Re: Non-executable stack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 00:23:51 -0000 martinko wrote: > Julian Elischer wrote: > >> Dag-Erling Smørgrav wrote: >> >>> db writes: >>> >>> >>>> Memory on ia32 can be writable and readable. When it is readable it >>>> is also executable. On other arch's like AMD64 and IA64, I believe >>>> memory can be readable, writable and executable. >>>> >>> >>> >>> >>> Not quite. IA32 can make individual segments readable, writable and / >>> or executable, but lacks the ability to do so on a per-page basis. >>> Since we have trampoline code at the top of the stack, the entire >>> stack segment must be executable. Moving the trampoline off the stack >>> would solve the problem on all platforms. >>> >>> >> >> There has been recent talk of a shared kernel/user memory page.. >> that could be used for trampoline code. >> >>> W^X across the board is not an option - it would break HotSpot and >>> other JIT-based software. >>> >>> DES >>> >>> >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to >> "freebsd-security-unsubscribe@freebsd.org" >> >> > > and what exactly is that trampoline btw/pls ? the way that signals are deliverred in non threaded code, is that they are always delivered when the processor is returning to userland after having been in the kernel for some reason (a hardware interrupt, or a sheduler change or a syscall or a pagefault, it doesn't matter why). The kernel places code on the user stack, that calls the signal handler and then returns, returning to whatever is next on the stack, which is the return address that it would have gone to when returning from the kernel had the signal not happenned. The code has to know how to get ready to call a signal handler, call it and cleanup anything that needs to be cleaned up after a signal handler. It's placed on the stack as it's guaranteed to exist and it all cleans up after itself., requiring no further work from the kernel. It does however require that the stack is executable. it allows the kernel to always supply a working signal handling stub. With a shared page (readonly to the user), the kernel could permanently place a good stub handler there. > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org"