Re: Support Grsecurity/PaX

Kevin P. Fleming (BLOOMBERG/ 731 LEX)

(sorry for top-posting, our message system doesn't believe anything else is possible)

The funding for the fuzzing project is intentionally short-to-medium-term, with two goals: helping to learn the 'state of the world' (which will feed into the census, and future support/funding decisions), and producing better and easier-to-apply fuzzing tools so that project teams can run them on their own software to identify flaws as early as possible. It's definitely not a long-term 'fuzz test the world' project.

The funding for Frama-C is for further development of the tool (and related tools), not funding to do static analysis of large bodies of open source software.

As a result, neither of these are suitable comparisons to the request for funding of grsecurity/PaX. Such a request would be more comparable to funding OpenSSL, ntpd, etc. Those are also not open-ended funding commitments, but are based on achieving improvements (in some cases, milestones) to continue funding. It's certainly possible that the SC would consider a funding proposal for grsecurity/PaX, but such a proposal would need to include reasonably well defined goals/milestones, and there's no question that the committee discussion would include the topic of the in-tree/out-of-tree status of these tools.

From: pageexec@... At: Aug 19 2015 17:56:13
To: Jason@..., dankohn@...
Cc: cii-census@..., cii-discuss@..., spender@...
Subject: Re: [cii-census] Support Grsecurity/PaX
On 19 Aug 2015 at 13:37, Dan Kohn wrote:

Hi Dan,

> On Wed, Aug 19, 2015 at 11:32 AM, Jason A. Donenfeld <Jason@...> wrote:
> > Of course there are worthwhile
> > kernel projects that are not a part of mainline.
> One last question for you: could you name other such projects (not
> necessarily security-related). Nearly every other out-of-mainline
> project I'm aware of has eventually either merged or died out.

Let's hope you only had bad luck and that's why you aren't aware of
any of these ;)

As for the requirement of mainlining grsec, it's not possible since
we know right off the start that some of the features and other changes
are not acceptable at all (say, all the x86 segmentation based code).

Second, for the potentially viable pieces this would be a multi-year
full time job. Is the CII willing to fund projects at that level? If not
we all would end up with lots of unfinished and partially broken features.

Third, you're actually wrong as to what is needed for mainline acceptance,
it's most definitely not enough to dump the code on them and let the
community figure it all out and take care of it. If anything, the exact
opposite is true, for any non-trivial amount of code there has to be a
pledge for long-term maintenance from the submitters (so regardless where
grsec stays, in-tree or out-of-tree, the maintenance burden would still
be ours for some years at least, with corresponding need of funding).

Fourth, you mentioned the potential futility of not funding grsec indefinitely.
It begs the question why it is then worth doing the same for the fuzzing
project or Frama-C. I hope noone at CII believes that a year or two of
fuzzing and static analysis will exterminate all bugs so what happens after
their funding runs out? Or are you suggesting that they can be funded
indefinitely but for some reason grsec could not be?

In any case, it is your money and decision at the end and we thank you
for your attention at least. However it is also clear that we have a
different understanding of what constitutes securing the core infrastructure.

PaX Team

cii-census mailing list

Join to automatically receive all group messages.