The PaX team wasn't involved in this, but I had actually asked Linus back in 2004 if PaX would ever be accepted into the mainline kernel. His response meant that essentially no feature of PaX at the time (except for perhaps PAGEEXEC on some non-x86 architectures) would be accepted. For record-keeping purposes, here's the mail:
Date: Sun, 12 Dec 2004 10:35:53 -0800 (PST)
From: Linus Torvalds <email@example.com>
Subject: Re: memory leak in drivers/net/wan/cosa.c
On Sun, 12 Dec 2004 firstname.lastname@example.org wrote:
> While I'm on that subject, would it ever be possible to PaX
> (http://pax.grsecurity.net) merged into the mainline kernel?
Hmm.. I usually don't merge stuff unless users actually ask for it, and I
haven't seen much discussion there.
That said: I absolutely _detest_ anything that does x86 segmentation. I
actually try to kill all uses of segmentation, it's a horrid thing, and
it's finally going away. NX makes the last reason for it obsolete, and I
don't want to add kernel code for something I dislike _and_ believe has no
Also, randomization is similarly on my list of "absolutely evil" cases,
simply because it makes one of my pet things unusable: prelinking. I think
program startup costs are about the most importatnt things there are in
life (well, in _kernel_ life, at least), so pre-linking ends up being
something I consider very important. That means that randomization falls
under the heading of "not for regular use" as far as I'm concerned.
Of course, people who are really security-conscious may well want to do
randomization, I just dislike it as a _standard_ thing. But if it isn't
standard, then it has little point, methinks - the whole point is to make
it harder to attack standard installations, no?
> If you would be interested in merging at least parts of the code, the
> PaX team would be willing to do the work to have it included.
I don't have anything against merging individual features that would make
it easier for you guys, but see above on what I consider to be primary
objectives: no obsolete hw features that mess up generic code, and fast
process linkage startup. Which is why I tend to like a static NX kind of
But any particular detail I'm more than happy to have argued for, for
> BTW, in arch/i386/kernel/entry.S, there is an information leak of the
> ebp kernel register. A fix for it has been in the PaX patch, but
> basically the solution is to add "xorl %ebp,%ebp" after "jne
Yes, that seems to be a perfectly valid thing to do, although the only
thing it leaks is just the thread info address, so it's not like it leaks
random information that might contain any interesting data depending on
which system call it was. But an xorl is certainly not expensive, and it's
nicer to not leak anything at all.