On 27 Jan 2007 at 19:40, [EMAIL PROTECTED] wrote: > If I paxctl -PS the ioquake3 binary it crashes on startup with the error: > > PAX: execution attempt in: /dev/zero > > logged to the syslog. If I paxctl -ps ioquake3 it runs fine. Of course > mprotect is disabled in both cases.
this is then a sign that the application doesn't create its mappings with proper access rights, that is, it's mmap'ing without PROT_EXEC and then tries to execute code in there. having grepped through the quake3 sources i can't find any mention of /dev/zero, so it might be a library or something, only further debugging can reveal it (and it's an application bug somewhere, so it should be found and fixed). second, i also looked at how the quake3 engine generates code at runtime and i think the i386 port should follow that amd64 version which puts it into a file then mmap's it - this can run with full PaX permissions (of course, this mitigates the issue to filesystem access control, but is still better than in-memory JIT compilation). third, the Makefile has the HAVE_VM_COMPILED option, if you set it to false, it should use the interpreter instead and would again allow full PaX enforcement (but i guess it also costs performance, would be worth a measurement). > If I use the SSP-enabled toolchain, I'll loose my ability to toggle this > protection off and on at will right? correct. > Am I correct that the only work arounds in this case would involve > some kind of recompiling with per-package flags, etc.? it's not some kind of recompiling, it's recompiling ;-). and the way to control ssp use is via gcc specs file, that is, you'd have to switch to a nossp profile before emerging quake3. -- [email protected] mailing list
