Ed, Rik, All, > grep for "unchecked" in the kernel/verver subdirectory (of a vserver+grsec > patch that i made before)... that will give you a list of "unchecked" > atomic definitions, which means they don't cause a refcount overflow panic > in the kernel (if you enabled refcount checking). But as i said, i'm not > 100% sure that 's pax-stuff. When PaX is prepared for mainline the PaX team switches vanilla atomic reference counters to unchecked variants when overflow is expected, all others are checked. You need to know which counters from the Vserver patchset are susceptible to intentional overflowing so they are exempted from the refcount checks PaX preforms. As for the grsecurity patchset, I'd argue that there are a lot of desirable features that do provide additional security to the resulting kernel. Some examples: 1. CONFIG_GRKERNSEC_KMEM This helps tamperproof kernel space by preventing known ways of introducing code to the kernel http://www.linuxjournal.com/magazine/anthony-lineberry-devmem-rootkits http://lwn.net/Articles/328695/ 2. CONFIG_GRKERNSEC_MODHARDEN Having this setting would have prevented sock_sendpage and the more recent rds kernel exploits from working correctly http://www.grsecurity.net/~spender/wunderbar_emporium2.tgz http://xorl.wordpress.com/2010/11/08/grsecuritys-grkernsec_modharden-protection-and-the-rds-local-root-exploit/ 3. CONFIG_GRKERNSEC_HIDESYM A lot of exploits bank on the fact that distros ship pre-built kernels with known symbol tables (provided with package). The exploit simply fingerprints the kernel and uses addresses gleaned from this information, by compiling your own kernel and with hidden symbols it really makes it a guessing game for the attacker. 4. CONFIG_GRKERNSEC_BRUTE This complements #3, without a measure to prevent brute forcing #3 just slows attackers down. I know it takes a considerable amount of work to maintain this patchset and I'm not suggesting that you should/shouldn't do a pax+vserver only kernel, I'm simply highlighting some features in grsecurity that I see as desirable. I think dismissing the grsecurity portion simply as access control and chroot hardening is a gross oversimplification (I'm not suggesting that this was necessarily your intent). -- Kyle