Date: Sat, 29 Jun 2002 15:13:58 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: arch@freebsd.org Subject: Time to make the stack non-executable? Message-ID: <3D1E3126.C96FFAA5@mindspring.com> References: <3D1E28ED.B67A5271@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Barton wrote: > Subject: We're famous >http://story.news.yahoo.com/news?tmpl=story&ncid=70&e=2&cid=70&u=/cn/20020629/tc_cn/940585 Sean Eric Fagan and I discussed this several years ago, and we discussed it again the other day, before this attack hit. It looks like it's an idea whose time has come. We've identified a number of issues that might make doing this problematic, and on which there needs to be feedback: o Java; specifically, JITs may rely on an executable stack. Neither of us knows if this is true, for sure. o FORTH? Same question. o Signals o Julian's new threads patches o Multiple architecture support Right now, SEF points out (and I concur) that the only portion of the system that seems to care about having an executable stack is the signal trampoline. I would imagine that the trampoline for the user space threads scheduler for KSE based threading will (does) have the same problem. For signals, this is easy: copy SVR4, and modify the signal functions to pass in a return address, then disable the execute bits on stack pages and see whose head blows up. Frankly, I'm very surprised to discover that OpenBSD has not already done this. Opinions? Patches from people who know and love the signals facility on Alpha, SPARC64, PPC, etc.? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D1E3126.C96FFAA5>