From owner-freebsd-sparc Sun Oct 27 10:35:25 2002 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 993E537B401 for ; Sun, 27 Oct 2002 10:35:23 -0800 (PST) Received: from k6.locore.ca (k6.locore.ca [198.96.117.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id F238D43E42 for ; Sun, 27 Oct 2002 10:35:22 -0800 (PST) (envelope-from jake@k6.locore.ca) Received: from k6.locore.ca (jake@localhost.locore.ca [127.0.0.1]) by k6.locore.ca (8.12.5/8.12.5) with ESMTP id g9RIlRbd010705; Sun, 27 Oct 2002 13:47:27 -0500 (EST) (envelope-from jake@k6.locore.ca) Received: (from jake@localhost) by k6.locore.ca (8.12.5/8.12.5/Submit) id g9RIlQxd010704; Sun, 27 Oct 2002 13:47:26 -0500 (EST) Date: Sun, 27 Oct 2002 13:47:26 -0500 From: Jake Burkholder To: John Polstra Cc: sparc@freebsd.org Subject: Re: Is the sparc64 stack segment executable? Message-ID: <20021027134726.J89245@locore.ca> References: <200210262328.g9QNSrkn045622@vashon.polstra.com> <20021026224039.F89245@locore.ca> <200210271807.g9RI7dZC046984@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200210271807.g9RI7dZC046984@vashon.polstra.com>; from jdp@polstra.com on Sun, Oct 27, 2002 at 10:07:39AM -0800 Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Apparently, On Sun, Oct 27, 2002 at 10:07:39AM -0800, John Polstra said words to the effect of; > In article <20021026224039.F89245@locore.ca>, > Jake Burkholder wrote: > > > > Next question: Assuming the stack is not executable by default, would > > > > it work for the application to make it executable using mprotect? > > > > > > Yes. > > > > Gcc is not generating the calls to mprotect. Its a simple fix, > > Yes, I saw the stuff in sol2.h that takes care of it. It sure is > ugly, though. Every time you pass the address of a nested function, > you have to make a system call. > > I suppose there must be some good reason why the stack isn't > executable by default ... right? There are a couple reasons, I don't know how good they are. 1) Its specified by the ABI that the stack should be mapped non-executable. 2) Mapping anything executable adds pmap overhead because the instruction cache is not coherent with stores. The compiler and the dynamic linker use the right instructions to synchronize the instruction cache, but for example executable code that's copied by the kernel into user pages doesn't, so pmap needs to flush pages that are mapped executable from the instruction cache manually. This is not handled particularily well by the kernel yet, but it still adds overhead so the less things mapped executable in general the better. 3) It provides some protection from stack smashing attacks that copy code there unless they somehow arrange to do the mprotects. Maybe this is security through obscurity though :) The idea is that code that does this is in the minority so overall its a win. The code that gcc generates can be made to do a sysctl or something on startup, so the stack protections could be made a tunable to avoid the system calls if its not confgured that way. Does modula-3 do this a lot? > > > I'll try to get it committed and get gcc on panther upgraded as > > soon as I can. > > Thanks, but there's no rush (see below). To fix it were you just > going to copy the definition of TRANSFER_FROM_TRAMPOLINE from > into ? Yes. This works, I've built a compiler that does this and your test program runs. Jake > > It would be good to fix it in gcc eventually, but don't rush to do it > on my behalf. Modula-3 uses its own version of the gcc sources for > its code generator, so fixing the system gcc won't make any difference > there. I guess I can put the fix into the Modula-3 version to get > it working -- or I can use a different approach. The original M3 > code generator avoided the trampolines altogether, but that involved > patching more of gcc. Up until now, I've managed to get by with > simply adding new files to gcc-3.2. I haven't had to patch any of the > stock source files. > > John > -- > John Polstra > John D. Polstra & Co., Inc. Seattle, Washington USA > "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message