The future for grsecurity

we'd like to clarify a few statements in the article. the most important fact from which everything else follows is that contrary to what is assumed in there, we never ever considered submitting grsecurity or PaX for mainline inclusion, and therefore obviously we never have. anything similar in the past was user action, not on our behalf (including the one post cited explicitly in the article), and without as much as a CC to us in fact. so any criticism about what we did or did not do to comply with mainline submission guidelines is, to be polite, misguided at best.

now that this is clear, you might however be interested in why things are this way. there's more than one reason actually, in no particular order:

- break up and submit

it doesn't work in our case. to understand, you'll have to consider that we've been doing these projects for over 8 years in entirely our free time. free time happens to be precious and is therefore subject to heavy optimization. you can call that being lazy if you like, but the fact is, we are unwilling to waste this resource. if breaking up and submitting parts of the patches don't in the end reduce our workload on maintaining the rest, then it's simply not worth it. and so it happens that there're several features that will never be accepted in mainline (arguing their justification in another question and would surely be subject to flamewars, so we'll leave it at that ;) and they also happen to be the most maintenance-heavy features, so effectively our workload wouldn't be reduced by much (and even if it was worth it, our free time is simply not enough to accomplish this task).

- acceptable features vs. our sanity

lest you believe Linus, you may want to look at what PaX does vs. what he claimed it did and you'll realize that he was talking about something else, most likely Exec-Shield (PaX provides normal per-page PROT_EXEC semantics on i386 unlike the approximation in Exec-Shield). that's little wonder of course given how he couldn't have seen the code that was never submitted.

but speaking of features, we have another reason for not submitting the patches: we've always had several features that build up on or augment each other. say, in PaX there's a conscious effort to provide kernel self-protection against kernel bugs. it's not a simple thing and several steps are taken to accomplish it (not implying it's a complete protection though). due to their implementation, some of these steps would never be accepted by Linus but then the rest doesn't make any sense either (say, properly limiting the per-cpu data segment is pointless without the proper userland/kernel virtual address space separation feature).

in other words, everything we have in the patches serves a purpose, regardless of whether a kernel developer (who isn't a security expert) understands that purpose or not.