PaX, a patch for the Linux kernel, is a central part of the Hardened Gentoo
project. PaX provides various functionality such as ASLR and NX memory. More
information is available at
The specific feature of PaX of interest in this article is MPROTECT, which guards against executable code in a program's address space. One of the main features of Hardened Gentoo is the ability to run PaX effectively because of the ET_DYN/PIE base. The eventual goal for Xorg is to have the binary itself built as ET_DYN/PIE to remove text relocations from it and randomize the base address without the EX_EXEC performance hit.
At this point, compiling Xorg with PIC code sounds like an obvious, logical choice. Hardened Gentoo offers hardened gcc for this purpose, which provides transparent PIE/SSP compiling. This is where you begin to run into problems with Xorg. Xorg currently uses elfloader to handle loading the modules it needs, however elfloader is unable to resolve various types of relocatable symbols that are always generated by PIC code. Most importantly, the elfloader has no support for Global Offset Table (GOT) or Procedure Linkage Table (PLT) type symbols which are both essential for shared libraries.
So if elfloader won't work then what will? Luckily there is already a fully operational, well tested, mature dynamic loader installed on your system. It is ld-linux.so which is provided by glibc. The obvious idea that occurs at this point, is that ideally there would be a programmatic interface to the glibc loader, and the X loader could be modified to use that instead of home-brewing its own loader. Turns out that such an interface exists - dlopen(3) et. al. - and this is exactly what the dlloader uses.
The option 'CONFIG_PAX_KERNEXEC' is the kernel land equivalent of PAGEEXEC and MPROTECT. By enabling this option, it will get harder to inject and execute 'foreign' code in kernel memory itself. This option may also give you some strange experiences on a hardened Xorg setup (being the Mouse pointer being stuck on the left side of the screen). Suggestion therefore is, to turn this option off by deselecting it in your config.
Enabling this option will result in all ioperm(2) and iopl(2) calls returning an error message. ioperm(2) and iopl(2) might be used to modify the running kernel. As you wish to run a Xorg server on top of your hardened kernel (mostly GRsecurity), you'll have to disable this config option, in order to get the XServer up and running.
Since Xorg 7.0 and up uses the dlloader instead of the elfloader by default, there is no need to do anything special to get Xorg compiling and working on a hardened profile.
You can setup your Xorg configuration file using The X Server
Configuration HOWTO found at:
Hardened Gentoo makes the default link strategy to resolve all symbols at load time, and enforces this on all shared libraries when they are built. Normally the loader uses "lazy" resolution if requested, whereby symbols are resolved as and when they are used. Unfortunately some Xorg modules have mutual dependencies and other issues that mean they cannot load unless lazy symbol resolution is enabled. To work around this issue, currently Gentoo compiles the Xorg modules and the server itself with the -nonow gcc flag. This fixes the "dlopen: undefined symbol" errors so previous methods of manually detecting and loading modules are no longer needed.
Binary drivers are currently not supported on the hardened profile and you are encouraged to use the opensource drivers instead.
The PaX flags -P (PAGEEXEC), -S (SEGMEXEC), -M (MPROTECT) as well as -R (RANDMMAP) now work with Xorg.