1. cii-census@lists.coreinfrastructure.org

Re: Support Grsecurity/PaX

Kevin P. Fleming (BLOOMBERG/ 731 LEX)
 

I believe I may not have communicated my thoughts as clearly as I should have, so I'll attempt to clarify :-)

First, it's absolutely true that long-term viability is a component of funding decisions. A goal of funding any project is to allow it to reach a point where it can be self-sustaining at a level that allows it to produce high-quality software, respond well to its users' demands, and continue adapting to the changing needs of the community. Some projects have had difficulty reaching that point on their own, so CII funding has been put in place to get them jump-started, but the CII doesn't plan to be their sole funding source indefinitely. That's why I said that a funding proposal would need to include clear objectives, so that there's a visible path to being self-sustaining.

When I commented on the comparison to the fuzzing and Frama-C projects, I wasn't commenting on the nature of the software involved, I was commenting on the structure of the funding proposals (hypothetical, of course, in the case of grsecurity/PaX). The funding proposals for the fuzzing project and Frama-C, by their nature, have definite horizons, and the goals are to produce tools that the community will adopt in such a way that CII funding is no longer needed for the projects to survive and thrive. The CII might still fund them in order to allow them to grow at a more rapid pace, or to explore research that might not be supported by other community members, but those would be *new* funding proposals.

So, my point with in both situations is that the CII steering committee is unlikely to review, and definitely not approve, a funding request that is essentially just employing the project's developers to continue what they are doing. In each case as we've considered a funding proposal, the most important aspects have been measurable, objective improvements in the project's health (measured in a number of ways, of course). While I certainly can't speak for the entire committee, I have no doubt that a significant item of discussion around a grsecurity/PaX proposal would be the effectiveness of funding a project whose codebase is not incorporated into its 'host' project, and whether such incorporation would be a suitable objective. Clearly, if these tools *could* be merged into Linux proper, they would likely see even greater adoption, and they'd benefit a much larger audience than they do today.

From: pageexec@... At: Aug 21 2015 15:40:49

On 21 Aug 2015 at 18:19, Kevin P. Fleming (BLOOMBERG/ 731 LEX) wrote:

Hi Kevin,

first of all, thanks for your detailed response and new information that
I was not aware of. However as much as it clarified some points, it also
raised new questions. You see, I brought up the issue with fuzzing and
static analysis because Dan Kohn said this earlier:

> Jason, if CII funded Grsecurity/PaX for a year or two, it would keep
> the project going, but then what? It is unlikely that CII could fund
> the project indefinitely, so it would remain an unhealthy project.

The way I read this response suggested to me that long-term viability is
an important (and possibly deal breaker?) factor in your funding decisions.
Now you are saying that it was not for the mentioned projects. This leaves
me confused as I do not know what applies and does not apply to a project
such as ours.

You also said that grsecurity was not comparable to fuzzing/static analysis
and is more like a standalone(?) product. I beg to differ here as we produce
much more than just a kernel patch albeit it is perhaps less advertised.
Namely, due to the nature of our proactive defense mechanisms (both runtime
and compile time), they are also good at catching bugs (almost always with
security impact) and we have found and fixed a number of them for the past
few years. One would think that exposing such technologies to a wider audience
would have a much bigger impact on everyone's security than our own limited
efforts.

cheers,
PaX Team
Join cii-census@lists.coreinfrastructure.org to automatically receive all group messages.