I run a server with PaX and grsecurity but lately I've been wanting to do a web lisp project. Sadly SBCL really doesn't get along with memory randomization. I've downloaded the binaries off off the site and I can use paxctl to turn it off for them and then they run just fine, so that's a start, but they are old and I'd like to configure mine. So it comes down to trying to compile my own. So I have a working SBCL binary which I use to compile the .lisp into a cold-core and turn on a vanilla-gcc profile and compile a new SBCL binary. Then again turn off stuff with paxctl and the binary runs, but when I try to get it to load the cold core (as in make-target2.sh) as part of the build process, it stalls out and uses 100% of the CPU.

Anyone have any idea why this might be happening or what I can do to test more?

Is there a way to turn PaX off selectively? I remember when Feodra/RHEL first added some of the memory randomization features standard, there were some issues with SBCL. Juho worked with Arjan at Red Hat to work out something that would allow SBCL to work. I don't remember exactly what did the trick, but I believe they did something to turn off randomization so that SBCL could load its core files where it expected in the memory map.

Yep, and I can do that on precompield binaries and they work fine. But either the binary my system is compiling is still defective in some subtle way even after also turning off memory randomization for it, or the cold core file that is being generated for it by the binary SBCL is messed up. Either way, between the two of them, when I start the freshly compiled SBCL (with mem rand turned off) with the cold core file it stalls at 100% cpu usage.

Awesome, thanks. The full environment is a hardened Gentoo box. I wrote a quick setuid script turn off all pax features of a binary and have tweeked the ebuild to run it on the binary it uses to compile the cold core and to run it on the generated binary, and then I turned on a vanilla GCC profile instead of the pic and pie and other security features normal profile and started the emerge compilation process, and as I said, in make-target2.sh when it gets the fresh binary to load the generated cold core, 100% cpu usage. I've tried playing around with it after I ctrl-c killed it and nothing. If you need any more info, please ask.