Date: Sun, 27 Oct 2002 13:47:26 -0500 From: Jake Burkholder <jake@locore.ca> To: John Polstra <jdp@polstra.com> Cc: sparc@freebsd.org Subject: Re: Is the sparc64 stack segment executable? Message-ID: <20021027134726.J89245@locore.ca> In-Reply-To: <200210271807.g9RI7dZC046984@vashon.polstra.com>; from jdp@polstra.com on Sun, Oct 27, 2002 at 10:07:39AM -0800 References: <XFMail.20021026151445.jdp@polstra.com> <200210262328.g9QNSrkn045622@vashon.polstra.com> <20021026224039.F89245@locore.ca> <200210271807.g9RI7dZC046984@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jake@locore.ca> 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 > <config/sparc/sol2.h> into <config/sparc/freebsd.h>? 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021027134726.J89245>