According to the kernel config help for the GR security option "Deny writing to /dev/kmem, /dev/mem, and /dev/port", Xfree should work even with that option enabled (grsec should recognize Xfree's accesses to video mem and specifically allow them). It also worked that way up to gentoo-sources-2.4.19-r10: Xfree worked fine although that option was set in my kernel. With gentoo-sources-2.4.20-r1 and that option switched on, Xfree fails on startup because it gets a "permission denied" when mmaping the video memory.
you have to give permission to XFree to read it ... check out the grsec docs at http://grsecurity.org/
Hmmm, I'm a little bit confused. I didn't find much about Xfree and the mmap problem. I'm aware of Xfree's problems with grsec's non-executable stack pages, but that's definitely not the problem here. And grsec's "chpax" utility allows to switch the non-executable features on or off for a specific executable, but it doesn't allow to switch the mmap restrictions on or off for a specific executable, so how should I give Xfree the permission to perform its mmaps? Two more things confusing me: * Exactly the same configuration with exactly the same xfree worked fine with the old kernel, the kernel version is the only thing which changed. * I found notices in the grsec forum that for some vga cards, xfree is trying to access the video BIOS, which is blocked by grsec's mmap restrictions. I rechecked my xfree logs: They first contain an error message about being unable to access the BIOS, but xfree seems to continue after that error. The final and fatal error message is about being unable the mmap the framebuffer, but this mmap call seems to be fundamentally wrong: It tries to mmap the framebuffer at (0x00000000,0x1000), which should be 0xf0000000 or something like that I think!
grsec is a very dynamic code base ... it could be something that changed ...
Well, what version of grsec is in 2.4.20-r1? The patches.txt file doesn't contain the version! (for 2.4.19-r10, it was 1.9.7)
2.4.20-r1 has grsecurity-1.9.8-rc2
"It's a feature, not a bug...". You may close it. I had a close look, and I didn't like what I found: Kernel side: The grsec patch in gentoo 2.4.19-r10 offered kmem protection, but as far as I can tell from the source, it didn't affect mmap calls at all: They were not checked. In 2.4.20-r1, the grsec kmem protection only allows mmaps for write if they are bejond physical memory, or if the map video mem (0xa0000 / 0x20000). Anything else is blocked. (which is what we want and what the doc's state, fine). Xfree side: An strace of the X server shows dozens of r/w /dev/mem mmaps. There are four kinds of them: * mmap's of video mem - fine. * mmap's in the PCI address space (0xe....... and 0xf.......) - fine. * mmap's of the video bios (0xf0000 / 0x10000) - bad (why for write???). * mmap's of the interrupt table (0x0 / 0x1000) - absolutely horrible! So it's not a kernel problem - Xfree should be educated how to behave in a secure system.
Ok... thanks.
