From: Dave R. <ld...@dr...> - 2005-08-01 15:22:44
|
I did some sleuthing on the problem I encountered the other day (where SBCL dies in init with a SIMPLE-ERROR). As Zach Beane pointed out, the root of the problem is that recent Fedora core kernels are randomizing memory layouts as a security measure to try to thwart buffer overruns. If you're at all interested, Google for "exec-shield" and you'll get back some info. At first, I thought this was just a problem with Fedora/Red Hat systems. Zach first ran into it on Fedora Core 4. I'm running FC3 and hadn't seen the problem until I updated my kernel to something more recent (I'll often run without rebooting for months). These recent FC kernels have a /proc/sys/kernel/randomize_va_space knob which can be set to enable or disable the randomization. When exec-shield first came out of Red Hat, they would treat "legacy" binaries very gently, basically running the system the same as it was before unless the binary had been compiled with a set of switches to gcc that would mark some ELF bits saying that binary was "safe" (basically adding a stack segment to the ELF and disabling execution privileges to that segment). My first thought was that I had probably built the SBCL binary in a way that the kernel was thinking this was a non-legacy binary and that I would have to patch something in the sbcl build. After some sleuthing, I found out that there is no such switch. The only way to run sbcl these systems is to totally disable memory randomization, effectively shutting it off for everybody. Further, this is no longer a Fedora/Red Hat problem. The memory randomization technology has been merged into mainline kernel development and should be coming to a distribution near you very shortly. Thus, I think we have a problem with sbcl. Yes, we could simply tell everybody that sbcl requires memory randomization to be off, but you'll be setting yourself up for a stream of FAQs regarding this. Further, it basically puts a shot into any other package using sbcl as a base for other software written in Lisp. It's difficult to disable this global setting gracefully during a package install, for instance (it can be done, but since it's a global, it's very uncool to do so automatically). As a result of some questions I asked on the Fedora Developers list, I got Arjan van de Ven interested in taking a look at SBCL to see why it's having compatibility problems. Arjan is one of the kernel gurus at Red Hat and submitted the randomization patches to the kernel mainline development. In short, there's nobody better to help. Now, the rub is that I'm a complete idiot when it comes to sbcl internals. (I just hang out on this list to ask stupid questions and generally live vicariously through the lives of people far smarter than myself.) So, it would be great if somebody who understands the details of sbcl memory usage could work with Arjan. Any volunteers? Let me know and I'll hook you up. -- Dave Roberts <ld...@dr...> |