When the /dev/kmem protection in grsec is enabled, Xfree fails to start.
This protection disables all writes (including read/write mmap's) to /dev/mem and /dev/kmem.
Two exceptions are already hardcoded into grsec to make Xfree work:
* r/w mmaps above the physical RAM adresses (i.e. PCI address space) are allowed.
* r/w mmaps of the VGA framebuffer (0xa0000 / 0x20000) are allowed.
According to the grsec docu and forums, this suffices to run Xfree. It also looks very reasonable to me from a technical and security point of view. However, at least with my M7 notebook, it does not suffice to make Xfree work.
I analyzed Xfree's behaviour with strace. In addition to the two kinds of mmap listed above (which are allowed), Xfree makes many r/w mmap calls to the following two areas of memory (which are blocked by grsec and make Xfree fail):
* r/w mmaps of the BIOS (0xf0000 / 0x10000): Why? Isn't this ROM address space, which can't be written anyway???
* r/w mmaps of the first page (0x0 / 0x1000): Isn't that the system's interrupt table? I really want to have that protected from anything in userland, even if it is running with root priviledges! Nothing except for the kernel should be able to mess with interrupt addresses!
If grsec mem and kmem protection is turned off, or if the grsec code is patched to allow also 0xf0000 / 0x10000 and 0x0 / 0x1000, Xfree works fine.
Questions:
* Is this radeon specific or a general Xfree problem? Which parts of the code make these calls (there are several of them, to both areas mentioned)?
* Are the r/w accesses to the BIOS and to the first page really necessary, or could they be eliminated or at least made optional? I would be willing to trade in e.g. some autoconfiguration features like DDC for the additional security!
* Could the Xfree team and the grsec team please coordinate their efforts? I need both!
* Is there a list of Xfree drivers which work fine with grsec (i.e. perform r/w mmap's only to the PCI address space and the framebuffer)? This information would be helpful for future hardware investments, especially on security-sensitive systems...
Many thanks in advance for any information and improvement!
-- DI. Dr. Klaus Kusche Email: [EMAIL PROTECTED] WWW: http://members.inode.at/kusche Phone @ home: +43 7234 83894 Phone @ work: +43 732 673368 0 Private address: Buchenweg 15, A-4100 Ottensheim, Austria Office address: HTBLA Leonding, Limesstr. 12-14, 4060 Leonding, Austria or HTBLA Traun, Holzbauernstr. 20, 4050 Traun, Austria
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
