Grsecurity goes private

By Jonathan Corbet
May 4, 2017

On April 26, the grsecurity project announced that it was withdrawing public access to its kernel-hardening patch sets; henceforth, they will be available only to paying customers of Open Source Security, Inc., the company behind this work. This move has yielded quite a bit of discussion and no small amount of recrimination. It is not clear, though, that the right conclusions are being drawn from this change.

The grsecurity patch set is intended to harden the kernel against a wide range of potential attacks. Its mitigations range from simple techniques like making important data structures read-only to relatively advanced defenses like RAP. Over the years, the developers involved have certainly broken new ground and come up with some novel solutions; as a result, these patches are appreciated by a fair community of users — a community that has lost free access to this work in the future.

Grsecurity and the mainline

These patches have not, as a whole, found their way into the mainline kernel, for a number of reasons. One is the simple fact that the kernel development community historically has not fully appreciated the need for kernel hardening. There was an increasingly unwarranted level of confidence in the kernel's inherent security and a lack of desire to face the trade-offs that often come with hardening patches. As a result, Linux fell behind the state of the art in this area, and external patches like grsecurity were the best way to increase the kernel's resistance to attacks.

Over the last couple of years or so, there has been a shift in the kernel community that has made it more open to hardening work; the ongoing efforts of the grsecurity developers certainly deserve some credit for this change. As a result, a number of technologies, most inspired by the grsecurity work, have made their way into the mainline, though the code has often changed significantly (or been entirely rewritten) along the way. Current kernels have address-space layout randomization, post-init read-only memory, hardened user-space access routines, GCC plugins for the build process, reference-count hardening, virtually mapped kernel stacks, and more. There have been numerous complaints and snide comments, especially from the grsecurity camp (example), on how these features have been implemented, and it may well be that many of them are not as strong as one would like. But they represent progress nonetheless.

Why not just merge the grsecurity patches outright? Because that is not how the kernel community works. Changes to the kernel are split into small, reviewable changes, (sometimes) documented, and each is debated on its own merits. The grsecurity patches are not split in this manner and, in many cases, they do not meet the kernel community's standards in their current form. Like it or not, there are trade-offs to be made with any patch, including security patches, and those trade-offs, which may include performance and long-term maintainability issues, must be discussed.

Security patches tend to be discussed more fiercely than others, partly because some kernel developers see a relatively small advantage to them for a relatively large cost. The value of kernel hardening is more apparent to some than to others. But security is not unique in this way; getting invasive changes of just about any type into the core kernel is never an easy task. The grsecurity developers have had little interest in doing the work to get their patches into the mainline; the same is true of the bulk of those who use the grsecurity patch set.

Nothing obligates any of these people to put in that effort, but the implication is that this work will fall to others who are interested in seeing these patches upstreamed. Finding developers willing to take that task on and deal with the ensuing discussions has not always been an easy task, but the pace of upstreaming has increased in recent years anyway. Much of this work has been done under the aegis of the Kernel Self-Protection Project (KSPP), an informal group of whom founder Kees Cook is the most visible member.

Why grsecurity went away

The withdrawal of the public grsecurity patch set has led to a certain amount of finger pointing and recrimination, with many blaming KSPP or just about anybody except the grsecurity developers themselves for the change. Consider, for example, this statement from a group that calls itself "HardenedLinux" (or "h4rdenedzer0"):

As the result of a discussion inside h4rdenedzer0, we believe that Linux foundation is the culprit behind all this result that the commercial/individual/community users losing access to the test patches.

Or this post from Mathias Krause:

I think the main reason for Brad [Spengler] and PaX Team to make their work private is the increased amount of work [KSPP] has put on them without providing any valuable work in return. They just don't want to be forced to maintain and fix-up the variants of grsecurity/PaX features KSPP lands upstream.

Both claims are somewhat difficult to back up.

The Linux Foundation does not control kernel development and does not run KSPP. What the Linux Foundation has done is to fund, via the Core Infrastructure Initiative, some of the work to bring grsecurity features into the mainline. Paying for work on free software, intended to improve the security of the Linux kernel, does not seem like a particularly blameworthy activity, so it's not entirely clear why the Linux Foundation is being faulted here. There is talk of too many press releases; these do exist, including one issued on May 4, but it seems strange to expect that the Linux Foundation should not highlight the work it is doing.

The claim that KSPP is somehow making life harder for grsecurity is also hard to justify. Those developers need not participate in this upstreaming work, and they need not accept the results of that work if they prefer their own patches. They do have to keep up with the pace of kernel development in general if they want the work that the rest of the community has been doing, but KSPP has not created that issue — that is a well-known cost of maintaining an out-of-tree patch set. The upstreaming work has also brought benefits to grsecurity, demonstrated by the fact that grsecurity has incorporated that work into its own patch set, as outlined in detail by Cook.

Much of the discussion seems based on the notion that the kernel community somehow owes something to the grsecurity developers for their work. That viewpoint overlooks something important: the entire reason Open Source Security Inc. is in business in the first place is that it gets an entire kernel, for free, that is actively maintained and extended by about 4,000 developers every year. It is a huge gift for a group of developers who, say, want to create a security consulting company. They can never repay the value of that gift; indeed, even the largest contributors to the kernel get more from it than they put in. That is why they are contributors in the first place.

In a sense, all users of the kernel owe a debt to everybody who has contributed over the years. And every one of us who has contributed has made a gift to all Linux users. The value of the grsecurity patches is significant, but it pales in respect to the value of the kernel as a whole. Grsecurity is not special in relation to the vast body of other contributions on which it is built.

So public access to grsecurity was not withdrawn due to workload, and it was not withdrawn because its developers have been somehow cheated by the development community. There is a much more likely explanation here: the movement of hardening features into the mainline kernel poses challenges to the developers' business model, which depends on providing security features not found there. Closing off access is meant to slow that movement and preserve the differentiation of the grsecurity patch set. This decision is within their right to make, as long as they stay within the terms of the GPL (and there have been no serious claims that they have done otherwise), but it should be seen as what it is: a business move intended to keep their work proprietary in spirit.

The existing patch set will continue to exist, of course, and it may well be that some suitably motivated developers will work to keep it updated with future kernel releases. Meanwhile, the work to bring more security features into the mainline kernel will continue. The kernel will get more secure over time, even without the minimal involvement of the grsecurity developers. Hopefully they will be successful in their business and will draw some satisfaction that, through the process of upstreaming, their older work will eventually improve the security of hundreds of millions of kernel users.

Index entries for this article
Kernel	Security/Security technologies
Security	Linux kernel

to post comments

Grsecurity goes private

Posted May 5, 2017 9:12 UTC (Fri) by dany (guest, #18902) [Link] (18 responses)

I also hope they will create successful business model, but first they should rename company to Not-So-Open Source Security, Inc.

Grsecurity goes private

Posted May 5, 2017 9:29 UTC (Fri) by tlamp (subscriber, #108540) [Link] (16 responses)

They could argue that they make Security for Open Source Software and never said anything about their Software "Open Source-ness"... :)

But yeah I get what you mean.

I have to say, while not heavily involved with Kernel dev and security, I get a worse and worse picture by them and PaX.
Not really because the closed down, but rather their behavior in the past. They produced a lot of mockery and arrogance against people who really try to upstream security/hardening to the Kernel, which *is* hard, instead of helping them.

Kees Cooks reply to the opinion that KSSP is to blame for this is really worth a read:
https://lwn.net/Articles/721750/

I have no understanding for people blaming anyone else than the grsecurity Team itself for closing their source.

I wish them their luck and hope that they do well. I also hope that their talent may help the whole Linux Community someday again, as the Linux Community's talent does now help them.

Grsecurity goes private

Posted May 5, 2017 17:49 UTC (Fri) by faramir (subscriber, #2327) [Link] (15 responses)

>They produced a lot of mockery and arrogance against people >who really try to upstream security/hardening to the Kernel, >which *is* hard, instead of helping them.

Would that be anything like the mockery and arrogance that
the kernel's benevolent dictator engages in on a semi-regular basis? Large swaths of the "kernel community" seem to have no problem with that kind of mockery so I don't see why this would be a problem.

Grsecurity goes private

Posted May 5, 2017 19:52 UTC (Fri) by MatejLach (guest, #84942) [Link] (14 responses)

>Would that be anything like the mockery and arrogance that
>the kernel's benevolent dictator engages in on a semi-regular basis?

Just wanted to point out that the 'mockery and arrogance' relates to code that if shipped in the kernel you're running right now, would likely result in having a bad time. It is mostly tolerated because we all want a quality kernel and are most of us are glad that somebody is watching over it to ensure that and secondly, it is tolerated because Linus attacks code, not people.

Grsecurity goes private

Posted May 6, 2017 2:59 UTC (Sat) by roc (subscriber, #30627) [Link] (13 responses)

> It is mostly tolerated because we all want a quality kernel and are most of us are glad that somebody is watching over it to ensure that

That applies to almost any significant project.

> it is tolerated because Linus attacks code, not people.

A number of examples to the contrary are included here:
https://www.theregister.co.uk/2016/08/26/linus_torvalds_c...

I think the real reason his behavior is tolerated is because Linux is a very successful project and Linus is perceived (probably correctly) as being essential to it. Just like the legendary assholism of Jobs, Gates, Ballmer and Ellison was tolerated because they ran very successful companies.

We'll never know whether Linux would have been more or less successful if Linus was less prone to abusive language, but I think he sets a poor example.

Grsecurity goes private

Posted May 6, 2017 7:23 UTC (Sat) by niner (guest, #26151) [Link] (5 responses)

Actually the article you linked does not exactly support your statement. The article is all about how Linus offends people and calls them names.

The examples that actually were about people were:
* "calls own lawyers a 'nasty festering disease'"
* "David Howells was informed that he was "f*cking moronic""
* "Kay Sievers was dismissed as a "f*cking prima donna"" and
* "anyone who didn't follow his particular comment syntax style was "brain-damaged.""

So far it does indeed sound like Linux attacks people. But if you follow the links in the article and read up on the details, the picture changes.
What he actually said was: "this arguing for lawyering has become a nasty festering disease". He calls the behavior a disease, not the people.

What about David Howells?
The actual quote is: "Not without a lot more discussion first. Quite frankly, this is f*cking moronic." Again "this is", not "you are" as theregister would make you believe.

The original quote about comment syntax is: "Can we please get rid of the brain-damaged stupid networking comment syntax style, PLEASE?". So the style is brain damaged. No word about people.

The only instance where he actually was talking about a person is the quote about Kay Sievers. By now this looks much more like the exception than the rule.

All that said, I would hopefully use a different way to communicate if I were in Linus' place. But since I am not I cannot be sure.The swearing, the language, aggressiveness, they are usually a sign of desperation. I'm sure you know how it is to sense that something is just correct or very very wrong, the "this solution is so beautiful, it drives me to tears" or the "oh this is wrong on so many levels, it makes me cringe". When you develop software long enough, your gut feeling becomes much quicker than your reasoning. So you know something's terribly wrong on a glance, but to get other people to see this, via email nonetheless, can be most difficult and frustrating and an unlimited source for desperation. So even if I do not condone Linus' behavior, I can certainly understand it.

Now to get back on topic, I wonder if the same could be said about Open Source Inc.

Grsecurity goes private

Posted May 6, 2017 17:06 UTC (Sat) by drag (guest, #31333) [Link]

If Linus was interested in being PC and popular he probably would of taken Apple up on their offer and we would be down one angry megalomaniac-yet-benevolent dictator.

Grsecurity goes private

Posted May 8, 2017 20:31 UTC (Mon) by roc (subscriber, #30627) [Link] (2 responses)

The distinctions between "what you said is fucking moronic", "you are being fucking moronic", and "you are a fucking moron" are very fine.

Furthermore, people don't always carefully parse profane attacks to distinguish whether those attacks are against them or something they said, in order to make a rational decision as to offended to be.

Here's a fact: in the great majority of workplaces, schools, families and even in LWN comments, Linus-style discourse would be completely unacceptable.

> When you develop software long enough, your gut feeling becomes much quicker than your reasoning. So you know something's terribly wrong on a glance, but to get other people to see this, via email nonetheless, can be most difficult and frustrating and an unlimited source for desperation.

Sure, I have tons of experience with this myself. But gatekeepers in other projects, and even the majority of Linux kernel gatekeepers, are able to overcome these issues without Linus-style diatribes.

Grsecurity goes private

Posted May 18, 2017 15:41 UTC (Thu) by Zolko (guest, #99166) [Link] (1 responses)

The distinctions between "what you said is fucking moronic", "you are being fucking moronic", and "you are a fucking moron" are very fine.

actually, they're not. I teach my children not to say "you're an idiot" but to say "you did something idiotic". Or not to say "you're a liar" but to say "you lied". In one case, you condemn the person as a such and forever, in the other case you point out that the person did something bad, implicitly also saying that the next time that person shouldn't do that (bad) thing.

Grsecurity goes private

Posted May 19, 2017 2:41 UTC (Fri) by bronson (guest, #4806) [Link]

Both statements are harsh when you're on the receiving end. Sure, one version is technically better than the other, but that's not likely to change the outcome. People will still get mad.

Grsecurity goes private

Posted May 11, 2017 11:15 UTC (Thu) by dag- (guest, #30207) [Link]

I very much liked your statement "When you develop software long enough, your gut feeling becomes much quicker than your reasoning.".

Thanks for that :-)

Grsecurity goes private

Posted May 6, 2017 8:29 UTC (Sat) by flussence (guest, #85566) [Link] (6 responses)

Maybe it depends on the amount of (poisonous) political correctness in one's workplace culture.

I personally would prefer getting a Linus-style “this code you wrote is f**king awful, _and here's why_” response any day, to what I've seen members of large software projects engage in all too often: derailing any conversation they feel at threat of “losing” into a war of attrition through obsequiousness and nitpicking. That's puerile office politics, and for FOSS most people on the receiving end of it aren't being paid by the hour to work at the office in question.

Grsecurity goes private

Posted May 6, 2017 12:16 UTC (Sat) by jrigg (guest, #30848) [Link] (4 responses)

> I personally would prefer getting a Linus-style “this code you wrote is f**king awful, _and here's why_”

Same here. I think it's interesting that Linux has been around for over 20 years, but it's only relatively recently that people have started commenting on this. It feeds into the seemingly fashionable habit of taking someone's comment out of context and twisting it to make it sound more personally directed than it actually is (either for humorous effect, as in the Register, or because the person doing it derives some satisfaction from being offended).

Grsecurity goes private

Posted May 6, 2017 12:25 UTC (Sat) by liw (subscriber, #6379) [Link] (3 responses)

Ummm. Historical revisionism, much?

I contributed code to the Linux kernel in 1991, before the first release. The code is still there, with some modifications. Soon after I decided I didn't want to be involved with the kernel at a code level because I didn't like being roasted by Linus. It's not a recent phenomenon.

Grsecurity goes private

Posted May 6, 2017 12:34 UTC (Sat) by jrigg (guest, #30848) [Link] (2 responses)

> It's not a recent phenomenon.
I was referring to the public comments about it, not the phenomenon itself. I have only noticed widespread public discussion of it recently.

Grsecurity goes private

Posted May 7, 2017 14:07 UTC (Sun) by jond (subscriber, #37669) [Link] (1 responses)

Public awareness and discourse about Codes of Conduct etc. are a relatively recent thing, but does not suggest that the problem is new, just that it's finally being taken seriously.

Grsecurity goes private

Posted May 8, 2017 10:44 UTC (Mon) by jrigg (guest, #30848) [Link]

> ...does not suggest that the problem is new, just that it's finally being taken seriously.
That was my point. I find the apparent cultural shift interesting. People seem more likely now to interpret an irritable (but not personally directed) remark as an ad hominem attack when that was not the intent behind the words. Note that I am not condoning genuinely abusive behaviour here - I just don't think Linus' criticisms count as such.

Grsecurity goes private

Posted May 8, 2017 20:36 UTC (Mon) by roc (subscriber, #30627) [Link]

There is a lot of middle ground between Linus-style diatribes and "poisonous political correctness". That middle ground is where almost everyone lives in real life.

> I personally would prefer getting a Linus-style “this code you wrote is f**king awful, _and here's why_” response any day, to what I've seen members of large software projects engage in all too often: derailing any conversation they feel at threat of “losing” into a war of attrition through obsequiousness and nitpicking.

Those aren't the only two choices; this is a false dichotomy.

Grsecurity goes private

Posted May 15, 2017 15:19 UTC (Mon) by ortalo (guest, #4654) [Link]

Unless we give them more time to foolproof their current name...
Anyway, "What'in a name? That which we call a rose.."

Grsecurity goes private

Posted May 5, 2017 10:22 UTC (Fri) by armijn (subscriber, #3653) [Link] (3 responses)

This h4rdenedzer0 group disqualifies itself immediately by saying big corporations such as Intel just take and never give anything back. Of course, the statistics show the exact opposite.

Grsecurity goes private

Posted May 6, 2017 3:57 UTC (Sat) by citypw (guest, #82661) [Link] (2 responses)

Hi there, I'm a member of h4rdenedzer0. Can you give show your statistics about how those big corps contribute back to PaX/Grsecurity? Did you read those references in our announcement? This whole thing is more complicated that your "imagine". IMOHO, plz read my personal view and those references at least:

http://openwall.com/lists/kernel-hardening/2017/05/04/10

http://openwall.com/lists/kernel-hardening/2017/05/04/20

The fact is fact. No one can denied.

Grsecurity goes private

Posted May 6, 2017 7:34 UTC (Sat) by niner (guest, #26151) [Link] (1 responses)

Well Intel, since it was specifically mentioned, was for example the largest corporate contributor to the Linux kernel in the 4.10 development cycle: https://lwn.net/Articles/713803/

The Linux kernel, as mentioned in this very article, is what PaX and Grsecurity are based on and where those pull thousands of patches from with every rebase. And those patches include a lot of work done and paid for by Intel. And that's what those big corps contribute to PaX/Grsecurity.

Grsecurity goes private

Posted May 18, 2017 17:16 UTC (Thu) by tuna (guest, #44480) [Link]

I think this was the best comment ever on LWN, and that says a lot!

Does something prevent distributing the patches?

Posted May 5, 2017 13:35 UTC (Fri) by SLi (subscriber, #53131) [Link] (32 responses)

So, I wonder how this works. As far as I understand from the article and other media:

1. Previously there has been a gigantic patch released for each supported upstream kernel version, publicly available on the grsecurity site.
2. From now on, they will only provide the patch to individuals and organizations who pay.

Right?

But it's fairly clear they may distribute the patch either under GPLv2 or not at all, so what prevents one of those paying customers from posting the patch publicly? Or do they somehow rely on the customers' unwillingness to do so?

Does something prevent distributing the patches?

Posted May 5, 2017 13:41 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (29 responses)

If you release it, it seems they won't give you any more patches in the future.

Does something prevent distributing the patches?

Posted May 5, 2017 15:14 UTC (Fri) by ballombe (subscriber, #9523) [Link] (26 responses)

Just send it to wikileak. How will they know would leaked it ?

Does something prevent distributing the patches?

Posted May 5, 2017 15:59 UTC (Fri) by tlamp (subscriber, #108540) [Link] (21 responses)

It is really really easy to add a signature to code.

Just write a mini code processor which changes whitespaces in indentation here and there, use different variable names, use different code structure add some hidden unicode symbols, ...

An Leaker could naturally scramble it too, but the chance that he misses something is still there.
Having two subscriptions could be helpful here, but the subscriptions are quite expensive AFAIK.

Also a third party leakage could be compromised, how do you verify that? `Open Source Security Inc.` may not help you there.

A bit joking but also a bit serious with this.

Does something prevent distributing the patches?

Posted May 5, 2017 16:42 UTC (Fri) by ballombe (subscriber, #9523) [Link] (2 responses)

You only need plausible deniability. They cannot throw away clients on a whims.

> Also a third party leakage could be compromised, how do you verify that? `Open Source Security Inc.` may not help you there.

Someone with a subscription will tell you...

Does something prevent distributing the patches?

Posted May 5, 2017 18:28 UTC (Fri) by tlamp (subscriber, #108540) [Link] (1 responses)

> Someone with a subscription will tell you...

Then you also trust them, else the could be the one who leaked the compromised patchset.

Also even if you trust them you could make it hard to verify the validness of the leaked patch set, *if* they would release a code with a signature (I still doubt they would do that, this is merely a thought experiment). Comparing semantics is not always trivial, especially if you have thousands of thousands diffs on kernel code. Even if you are experienced kernel hacker you will still need quite some time if you really want to ensure nothing slips.

I never ever would apply a leaked security patch set to anything worth a dime for me.

If you have a trusted contact with a subscription the easiest way would be to just use their copy and stay silent.

Does something prevent distributing the patches?

Posted May 7, 2017 14:11 UTC (Sun) by jond (subscriber, #37669) [Link]

> I never ever would apply a leaked security patch set to anything worth a dime for me.

I'm not sure, but I don't think ballombe's hypothetical end-game was end-users blindly applying security patches themselves, rather the continuation of getting the useful bits mainlined.

Does something prevent distributing the patches?

Posted May 5, 2017 17:26 UTC (Fri) by xtifr (guest, #143) [Link] (10 responses)

It is really really easy to add a signature to code.

But hard to make one that won't show up for diff if two people cooperate to release the code. :)

Not that I'm suggesting anyone should violate a valid contract...

On the other hand, I would note that anyone who distributes a grs-ified kernel will be legally required to distribute their source as well. Which means they've now limited their market to those whose use of the kernel is entirely in-house. Or those willing to violate copyright. (Technically, violating the GPL, but that really means the same thing.)

Does something prevent distributing the patches?

Posted May 5, 2017 18:12 UTC (Fri) by excors (subscriber, #95769) [Link] (2 responses)

If you release n copies, I think you just need O(n^2) signature changes in your code. That way you can have one change that is unique to each copy, plus one change that's unique to each pair of copies. If two people cooperate to detect and remove their unique-per-copy changes, they won't detect the unique-per-pair change and you can identify and punish both of them.

Does something prevent distributing the patches?

Posted May 6, 2017 0:28 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

If you are going to release lots of different patchsets with different contents, then are you going to have lots of different binaries as well?

including changes for the sake of having unique source trees for every customer sounds like a maintenance disaster.

If you aren't shipping different binaries, then the source no longer matches the binaries and you aren't in compliance.

Does something prevent distributing the patches?

Posted May 7, 2017 3:30 UTC (Sun) by songmaster (subscriber, #1748) [Link]

If they are distributing a patch file which is modifying C code it is trivial to generate a different version for each customer. One way is go through the patch file and for some unique combination of + lines (ones that don't end with a back-slash) you add one or more spaces to the end of the line, or before any trailing ; or make some other trivial space change like this. Such a modification doesn't change the binary that gets generated at all, and if you pick only every hundredth + line or so it would be pretty hard for individual customers to discover and remove this watermark. Of course if customers collaborate they can discover the watermark and modify or remove it.

Assuming that each patch file is applied to a specific version of the upstream kernel I don't see any maintenance issues.

Does something prevent distributing the patches?

Posted May 5, 2017 18:22 UTC (Fri) by tytso (subscriber, #9993) [Link]

They wouldn't be violating a contract. If there was a contractual term that forbid them from sharing the grsecurity patch, then grsecurity would be violation of the GPL.

More to the point, it means that grsecurity can't be used for cell phones or IOT, or any use case where the grsecurity subscriber is not the end user. That's because the moment grsecurity shows up in a consumer device, anyone who has purchased such a device can demand source code from the manufacturer of the device, and the manufacturer would have to give them a copy of the sources, and hence, a copy of the grsecurity code. And if the manufacturer then loses all future updates to grsecurity, that's not tenable --- which means that no device manufacturer with an ounce of sense would pay $$$ for the grsecurity patches.

This means grsecurity has made it self pretty much irrelevant to the vast majority of the Linux ecosystem, and all of the Linux upstream development. This is their right to do, of course. But at this point it makes them no different than say, how Oracle is completely irrelevant to Open Solaris and its derivatives.

Does something prevent distributing the patches?

Posted May 5, 2017 18:41 UTC (Fri) by madscientist (subscriber, #16861) [Link] (5 responses)

> Not that I'm suggesting anyone should violate a valid contract...

A valid contract can't tell you that you can't distribute the code. That would be a violation of the GPL.

A valid contract can't tell you that you have to notify grsecurity if you distribute the code. That is also a violation of the GPL (by adding extra conditions on the distribution of the code).

A valid contract can't even say that if you distribute the code your contract will be terminated (at least, that's my IANAL opinion) because that is also clearly an added condition on distribution.

So, basically, you can voluntarily notify them that you distributed the code if you want to, or they can discover on their own that you did so, or suspect it or whatever. And, the next time your contract is up for renewal in the normal course of business they can elect to not renew the contract, at their prerogative, for any reason (well, other than civil rights violations etc.) They don't have to tell you why they declined renewal.

There is absolutely nothing wrong with redistribution: the GPL 100% guarantees your right to do it, and thousands of people have put in literally billions of dollars' worth of effort into Linux based on the understanding that this just fine. Under no circumstances should anyone who redistributes feel like they are cheating anyone or doing anything underhanded or unethical.

Does something prevent distributing the patches?

Posted May 5, 2017 19:47 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (3 responses)

> A valid contract can't even say that if you distribute the code your contract will be terminated (at least, that's my IANAL opinion) because that is also clearly an added condition on distribution.

Actually that's doable and it's been discussed many times through the years.

It's also not dissimilar from what Red Hat does with their binaries (they distribute the source, but redistributing the binaries can lead to termination of your support agreement).

Does something prevent distributing the patches?

Posted May 5, 2017 22:02 UTC (Fri) by madscientist (subscriber, #16861) [Link] (2 responses)

> Actually that's doable and it's been discussed many times through the years.

I'd be interested to see any such discussions that are directly applicable to that situation. If you're allowed to attach conditions that directly penalize the act of redistribution then you can have a contract that says "if you distribute the source you must pay $500 billion US", or other requirements that are equivalent to making redistribution of the source code illegal.

The Red Hat situation as you describe it is different: they aren't restricting distribution of the source code. The GPL doesn't talk about limitations on the distribution of binaries, only source code. The binaries Red Hat provides may contain other restricted works such as trademarks etc.

Does something prevent distributing the patches?

Posted May 5, 2017 23:39 UTC (Fri) by zlynx (guest, #2285) [Link]

Of course it is doable. If I agree to work for you as a contractor as long as you keep the air conditioning in your office set to 72 F, and you don't do it, and I quit, I haven't restricted you. I've set conditions on my working for you. If you break them, I leave. But I'm not stopping you.

Does something prevent distributing the patches?

Posted May 6, 2017 8:29 UTC (Sat) by paulj (subscriber, #341) [Link]

I don't think your comment is correct. The GPL gives people the right to distribute the binaries just as much as the source, and no one can remove this right from a recipient (least, not within the GPL). It's just that distribution in binary form comes with requirements to also ensure the recipient has access to the source (within reason).

Does something prevent distributing the patches?

Posted May 6, 2017 8:24 UTC (Sat) by paulj (subscriber, #341) [Link]

A valid contract can say "Nothing in this contract prevents you exercising your GPL rights, however once you do we have the right to terminate this support contract and/or not allow you to renew".

There are a number of companies with this business model....

Does something prevent distributing the patches?

Posted May 5, 2017 19:46 UTC (Fri) by boog (subscriber, #30882) [Link] (1 responses)

"Just write a mini code processor which changes whitespaces in indentation here and there, use different variable names, use different code structure add some hidden unicode symbols, ..."

Before leaking ensure that code from two sources has the same hash. Possible process to equalise white space etc to achieve that aim.

Does something prevent distributing the patches?

Posted May 5, 2017 20:39 UTC (Fri) by tlamp (subscriber, #108540) [Link]

> Before leaking ensure that code from two sources has the same hash. Possible process to equalise white space etc to achieve that aim.

Whitespace is by far the easiest, just remove them altogether where possible and let only one left where not possible.

But that doesn't help you against variable renames, structure renames, reordering, function signature changes.
They're patchsets are huge (yuge!) and they are far from stupid and far from non-creative, so they *could* do really a lot and make any tries to normalize the code not worth the try.

Normalizing is easier said than done, remember that you can implement same semantics in different ways and even a single character can make the kernel compromised if place correctly...

Now than I think seriously about this, to check that is equal to the halting problem.
If this was doable, like you say, prove it formally and you have solved the halting problem and thus get a few prices, a few millions of $ and a really lot of recognition.

Does something prevent distributing the patches?

Posted May 6, 2017 0:10 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link] (2 responses)

It is really really easy to add a signature to code.
Just write a mini code processor which changes whitespaces in indentation here and there, use different variable names, use different code structure add some hidden unicode symbols, ...

I think this would be a violation of the GPL, which requires that the code be redistributed in the preferred form for making modifications. It shouldn't be hard to argue that the preferred form for making modifications is the form the coders actually use when they're working on it, so that any attempt to watermark the code the way you're describing violates that term of the GPL.

Does something prevent distributing the patches?

Posted May 6, 2017 0:18 UTC (Sat) by sfeam (subscriber, #2841) [Link] (1 responses)

Good luck on that one. You're seriously arguing that whitespace affects the copyright status of a work?

Does something prevent distributing the patches?

Posted May 6, 2017 1:23 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link]

It's not a question of the copyright status of the code. Nothing a code mangling algorithm does would count as original authorship, which would be required to have copyright implications. The question is about compliance with the terms of the GPL, which requires that code be redistributed in the preferred format for modification. Mangling the code- and the grandparent went well beyond whitespace changes to things like changing variable names and even code structure- is at least arguably changing the code from the preferred form for making modifications to something else. Somebody who was actually going to sue over GPL compliance would be foolish not to include that in their complaint.

Does something prevent distributing the patches?

Posted May 7, 2017 13:18 UTC (Sun) by misc (subscriber, #73730) [Link] (1 responses)

So that would be quite interesting to claim to not have time to upstream, but still dedicate time to add a covert tracking system in a C patch.

Does something prevent distributing the patches?

Posted May 7, 2017 17:41 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link]

It's a grossly unfair comparison. Everyone knows that getting code pushed upstream is a long-term effort. Even in the best of circumstances it can take months, and when there are important kernel developers who are skeptical of the code it can take years. Writing a tool to watermark code by making non-critical changes is the kind of thing that could be whipped up in a day or two by anyone who cared to try. Tracking who got which watermarked version of the code would be a little more effort on top of that, but nothing drastic.

Does something prevent distributing the patches?

Posted May 7, 2017 13:11 UTC (Sun) by flussence (guest, #85566) [Link] (2 responses)

That seems like misguided effort.

On the other hand, grsec only has to bully *one* of their customers too far and they may decide to redistribute their copy of the commercial version to KSPP, with a small monetary contribution to cover the cost of mainlining the bits they want. It would probably work out far cheaper than the $17000 per year figure I've seen mentioned in one of these threads.

Does something prevent distributing the patches?

Posted May 7, 2017 18:30 UTC (Sun) by bronson (guest, #4806) [Link] (1 responses)

KSPP has mostly ignored the existence of grsec. (other than poaching high-level ideas of course) Not sure why they'd be more interested now that it's closed off.

Does something prevent distributing the patches?

Posted May 7, 2017 21:16 UTC (Sun) by bronson (guest, #4806) [Link]

On re-reading this, "poaching" isn't the right word... too negative. KSPP looked over the problems that grsec solved and selected a few to reimplement and push upstream. Not quite sure how to express that succinctly without adding political slant!

Does something prevent distributing the patches?

Posted May 7, 2017 14:10 UTC (Sun) by jond (subscriber, #37669) [Link]

> Just send it to wikileak. How will they know would leaked it ?

Sadly (IMHO), Wikileaks is not so interested in facilitating the leaking of anything that does not fit their current agenda/priorities. A lot of interesting stuff that used to be available via them is no longer, ever since the Manning leaks.

Does something prevent distributing the patches?

Posted May 5, 2017 19:13 UTC (Fri) by dmoulding (subscriber, #95171) [Link] (1 responses)

That in itself sounds like a clear-cut GPL violation to me. Telling your end users that they're violating some additional agreement (even if it's an unwritten agreement) with your company if they redistribute the code is adding an additional restriction on top of the GPL, which the GPL does not allow, for obvious reasons.

Does something prevent distributing the patches?

Posted May 5, 2017 21:47 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> Telling your end users that they're violating some additional agreement...

They're not doing that at all. Not only are you unconditionally free to use and distribute the patches under the terms of the GPL, you wouldn't even be violating any separate agreement you had with grsecurity by doing so. They just won't sell their future patches to anyone who has been known to distribute them in the past, which is well within their rights.

With all due respect to RMS, I think he's wrong on this one. It's a stupid and self-destructive move, as others have already pointed out, but not a violation of the GPL.

Does something prevent distributing the patches?

Posted May 5, 2017 14:44 UTC (Fri) by ballombe (subscriber, #9523) [Link] (1 responses)

It seems to me they are focusing on RAP now, which is a gcc plugin and not a kernel patch, and they do not need RAP to be under the GPL because the kernel is not linked to the gcc runtime.
That is how I understand the FAQ anyway.

Does something prevent distributing the patches?

Posted May 5, 2017 18:55 UTC (Fri) by madscientist (subscriber, #16861) [Link]

Maybe I'm not understanding what people mean by "GCC plugin", but as I understand it any GCC plugin has to be released under a GPL-compatible license... that was the entire reason why plugins took so long to be available in GCC.

So I don't see how using a GCC plugin allows escape from the GPL. You've only switched copyright holders from the Linux kernel community to the Free Software Foundation (sole copyright holders on GCC).

Now, if/when the kernel is able to be compiled with LLVM/Clang then certain completely proprietary plugins for that compiler can be made available under essentially any license.

Grsecurity goes private

Posted May 5, 2017 13:59 UTC (Fri) by madhatter (subscriber, #4665) [Link] (21 responses)

This decision is within their right to make, as long as they stay within the terms of the GPL (and there have been no serious claims that they have done otherwise)

Richard Stallman thinks that Grsecurity are violating the GPL. I'm not saying that he's automatically right, but it strikes me as a serious claim to the contrary.

Grsecurity goes private

Posted May 5, 2017 17:51 UTC (Fri) by xtifr (guest, #143) [Link] (18 responses)

Hmm, the link doesn't explain his reasoning, but I suspected as much myself.

If their argument is simply "sure, we allow you to distribute, as the GPL requires, but if you do so, we'll terminate your contract, completely separately from the GPL", then the problem is that they *can't* separate that from the GPL. Like many "obvious" ways to "get around" the GPL, it assumes the law is a Literal Genie which can only interpret words in their narrowest and most strict sense. This is not at all true--the law can and does take intent into account. And the *intent* here is clearly to restrict redistribution. Which is a violation of the GPL.

(Of course if, as someone suggested above, they're only going to be distributing a gcc plugin, and not kernel patches, then this *might* not be an issue.)

Grsecurity goes private

Posted May 5, 2017 19:04 UTC (Fri) by linuxrocks123 (subscriber, #34648) [Link] (17 responses)

They don't terminate the contract; they simply don't renew it. So, you get what you paid for, which is access to the current GRSecurity patches, but they'll refuse to sell you future revisions of the GRSecurity patches.

They're under no obligations to sell their work to customers they don't like, for whatever reason. They could, if they wanted, refuse to sell their work to a customer because the customer publicly supported a political candidate they don't like. I think they're in the clear.

Grsecurity goes private

Posted May 5, 2017 20:07 UTC (Fri) by xtifr (guest, #143) [Link] (10 responses)

Like I say, the law takes intent into account. It seems pretty clear to me that the *intent* is to prevent people from redistributing the GPL'd code. Of course, they'll argue otherwise. The only thing that matters, though, is what a *judge* would think. And I tend to doubt a judge would be fooled by such an obvious trick.

What might make it harder is if they *never admit* their reasons for not doing business with certain customers. That would switch the burden of proof. But even that would be a risky strategy, since it would be fairly obvious what they were actually doing.

Stallman's pretty experienced with people trying to weasel their way around the GPL. If he says it's a violation, I'd consult my lawyer before suggesting otherwise.

Grsecurity goes private

Posted May 5, 2017 21:57 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> It seems pretty clear to me that the *intent* is to prevent people from redistributing the GPL'd code.

If so it's a lousy way to go about it, since it doesn't actually *prevent* anyone from distributing anything. There will be a cost, of course, if you wanted their ongoing cooperation in the future in the form of new patches, but the choice is still yours whether to distribute or not. If you choose to distribute you are not violating any contract and do not lose anything to which you previously had any legal right. After all, there is no guarantee that there would *be* future patches for you to purchase, and even if they are created the authors are under no obligation to sell them to you whether you distributed the prior patches or not.

I could go around offering people a million dollars cash on the condition that they don't distribute any GPL'd code, without ever distributing GPL'd code myself. The *intent* of that offer would clearly be to reduce the distribution of GPL'd code (though not actually *preventing* it), but that doesn't mean that I've violated the GPL by making the offer.

Grsecurity goes private

Posted May 6, 2017 20:10 UTC (Sat) by paulj (subscriber, #341) [Link] (7 responses)

There are many other companies using this business model.

Grsecurity goes private

Posted May 8, 2017 22:30 UTC (Mon) by mattrose (guest, #19610) [Link] (6 responses)

Charging money for GPL-derived source code? Not the RH "charge money for binaries and distribute sources", or any one of a number of "Charge for additional binaries that happen to add on or plug in to the GPL-ed source code, but actual "You have to pay money for source code that you have every right to view and modify, under the GPL"

Name one.

Grsecurity goes private

Posted May 9, 2017 20:35 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

Email me or /msg me on freenode and I'll give you a link to one.

BTW, the GPL is perfectly OK with charging money for source code, and/or for binaries.

The only thing is that if you distribute binaries without source at the same time, then you must make the source available on reasonable terms. You can charge as much as you want for source and/or binaries, with that restriction...

Grsecurity goes private

Posted May 10, 2017 12:40 UTC (Wed) by mattrose (guest, #19610) [Link] (2 responses)

You are absolutely right about charging for source code, however, what the GPL is explicitly NOT ok with is putting "further restrictions" on the source code distributed or modified under the GPL.

Section 6 says: "You may not impose any further restrictions on the recipients' exercise of the rights granted herein."

RedHat complies by giving the source code away, and just charging for the convenience of pre-compiled binaries, and limiting access to those binaries, which the GPL says nothing about.

Look at it this way. I could have access to RedHat sources even if RedHat itself wanted nothing to do with me. For access to the source code for the grsecurity version of the linux kernel, I need to pay money to grsecurity. What grsecurity is doing is very much not only against the text of the GPL, but against the spirit of Linus's original license decision.

Linus put the kernel under the GPL because he wanted all of the modifications to it to become publicly available. All other contributors have contributed to Linux with the same condition. If Linus had wanted people to be able to fork off their own version and not contribute back, he would have licensed it differently.

And the fact that you are not willing to name one publicly kinda proves my point.

Grsecurity goes private

Posted May 10, 2017 13:33 UTC (Wed) by paulj (subscriber, #341) [Link]

Section 6 also applies to Section 3, where recipients are given the right to redistribute binaries (modulo reasonable access to source - which one is required to follow if one has distributed binaries, but that doesn't come into play if one only distributes in source form).

open source code gone dark

Posted May 19, 2017 4:29 UTC (Fri) by Garak (guest, #99377) [Link]

Linus put the kernel under the GPL because he wanted all of the modifications to it to become publicly available. All other contributors have contributed to Linux with the same condition. If Linus had wanted people to be able to fork off their own version and not contribute back, he would have licensed it differently.

I'm guessing that there are plenty of instances of people and businesses that modify GPLd code, and use it, often commercially, without making those modifications publicly available. It's just that those instances don't involve the distribution of those modifications publicly. I.e. one can readily imagine the NSA and CIA and Google hardening (some of) the kernels that they and their cohorts use without those modifications ever seeing any public light of day. Sorry to get pedantic about the nuance, but this does seem to be the place for it. Probably the CIA/NSA use some god-mode of legaleze to get around whatever they want, but there is clearly nothing illegal about making a business out of the fact that your secret unreleased/undistributed security enhancements give your IT infrastructure an edge over competitors. I.e. imagine a dozen hypothetical GMail competitors running modified linux kernels on their servers. The ones that get hacked the least make the most $$ in the long run. Obviously the hypothetical breaks down in the real world for lots of reasons, but I do imagine there are plenty of high profile businesses running servers with various secret sauce hardenings. Which is pretty much what this is all about AFAICT.

Grsecurity goes private

Posted May 18, 2017 20:15 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> You can charge as much as you want for source and/or binaries, with that restriction...

Except, that once you have distributed the binaries, you can NOT charge as much as you want for the source ...

I believe the GPL itself explicitly says you can charge a *reasonable* fee, and $1M for an hour's work for an engineer to copy the source to a CD is clearly not reasonable...

Cheers,
Wol

Grsecurity goes private

Posted May 19, 2017 7:34 UTC (Fri) by paulj (subscriber, #341) [Link]

For primary distribution, you can charge _whatever_ you want. Be that in source or binary form.

If you have distributed in binary-only form, you must honour the §3 commitments to provide source on reasonable terms, for _finite_ amount of time.

That does not, per se, prevent one from primary distribution in source form, at whatever price. (Though, anyone who is aware the distributor is also obligated to provide source under §3 terms, or is aware to ask, obviously may prefer the §3 terms).

Grsecurity goes private

Posted May 10, 2017 1:00 UTC (Wed) by linuxrocks123 (subscriber, #34648) [Link]

Intent only matters when the intent is somehow illegal by statute. Your claim that "the intent is to stop them from doing something they're legally allowed to do, therefore they can't do that" doesn't hold up to even a rudimentary analysis. In the US, a private company can, for instance, fire someone who goes on the news and says bad stuff about the company. The employee is perfectly free to speak up about how horrible his employer is, and the company is perfectly free not to be his employer anymore afterwards. No one's legal rights are being violated.

In the US, again, anti-retaliation laws are the exception, not the rule. You can't be fired for blowing the whistle on your company to the government, like by reporting it to the EPA or whatever, because there's a specific law against companies' doing that. You can't be fired or not hired for being black because, again, there's a specific law against companies' doing that. In some but not all US jurisdictions, you can't be fired or not hired for being gay, because there's a specific law against companies' doing that; in other places, there's no such law, so a company can only hire straight people and refuse to serve gay customers if it wants to, and can fire an employee for coming out, even though it's definitely not illegal to come out.

In the law, and not just the US but pretty much everywhere, anything not prohibited is permitted. If your assertion is that the law in whatever jurisdiction you're in prohibits a company from retaliating against customers for doing a thing, you'll need to find the specific law stopping the company from retaliating against the customer for doing that thing, not just confirm that the thing the customer did isn't itself illegal to do. Just because I have the right to go on the news and talk about how horrible McDonald's is doesn't mean McDonald's still has to employ me or serve me as a customer after I do that.

Grsecurity goes private

Posted May 6, 2017 7:26 UTC (Sat) by madhatter (subscriber, #4665) [Link] (5 responses)

They're under no obligations to sell their work to customers they don't like, for whatever reason.

That seems an over-simplified analysis, to me, at least in the context of England and Wales. Cases like this one have established that, at least once you engage in business, you do not have an overriding right to refuse to make a contract with someone, that there are some reasons which the law does not permit you to use to justify a refusal so to do, and that a court may make inferences about your real reasons if you refuse without giving a justification.

Let me be clear that I'm not saying that a customer's patch re-distribution is an unlawful reason for refusal in the way that a customer's homosexuality clearly is. I'm merely starting by pointing that out that unlawful reasons for refusal to enter into a contract do exist.

So one could argue that, Grsecurity having accepted a licence which forbids them to place restrictions on the GPL-compliant redistribution activities of inter alia their customers, they do not have the right to refuse to enter into a new contract with an ex-customer simply because that customer has engaged in behaviour which (s)he was perfectly entitled to do. I have no idea if such an argument would be persuasive, but it would need a better counter-argument than "Grsecurity don't have to enter into a contract with anyone if they don't want to", because that's simply not true.

Grsecurity goes private

Posted May 6, 2017 7:57 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

I don't know about England, but in the US companies can generally refuse service to another _company_ for any reason. Very much including "we don't want to deal with a company with a gay CEO" or "we won't sell our product to Democratic supporters".

There are certain limitations like local utilities and other regulated monopolies, and some cases of tortious interference, but they don't really apply here.

Discriminating against individuals is somewhat more complicated, the law in the US recognizes several enumerated "protected classes" ( https://en.wikipedia.org/wiki/Protected_class ). But "political opinions", for example, are not a protected class - it was absolutely legal for Hollywood to blacklist "communist supporters" during the McCarthy era.

Grsecurity goes private

Posted May 6, 2017 8:00 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> So one could argue that, Grsecurity having accepted a licence which forbids them to place restrictions on the GPL-compliant redistribution activities of inter alia their customers, they do not have the right to refuse to enter into a new contract
No problem. We have a very special price for your new contract: $100500 for each line of code that we deliver. Very cheap! Please send pre-payment checks to: .....

Grsecurity goes private

Posted May 6, 2017 8:48 UTC (Sat) by madhatter (subscriber, #4665) [Link] (2 responses)

Cyberax, I think the points in your first comment are excellent. I'm certainly not suggesting the English approach is persuasive everywhere, and the B2B vs. B2C distinction is well-worth closer examination (though if it were found to hold water, putting up an individual as a single protected transactor who could then redistribute without fear of comeback might well be something the community thought to do). I'm merely noting that linuxrocks123's argument is over-simplistic, and may not work everywhere.

The second comment's argument is again, to me, over-simplistic. You may wish to consider whether the court in Wilkinson would have found the B&B owner/operator's conduct less infringing if she had said "your room will not be £59.90, it will be £100,500 a night" instead of "no room for you"; my guess is they would have been equally unimpressed. All attempts to treat one customer differently to another are things a court may examine; the US-style position that I run my business how I like and I'll deal with customers how I like isn't always permitted elsewhere.

Grsecurity goes private

Posted May 7, 2017 9:27 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Hotels can't exceed publicly posted prices in the US... But within the posted limits a B&B most certainly can discriminate by, for example, political opinions or any other non-protected class. For example, a hotel can offer 99% discount to people wearing blue clothes.

Grsecurity goes private

Posted May 7, 2017 10:19 UTC (Sun) by karkhaz (subscriber, #99844) [Link]

Actual, slightly ridiculous example from the UK: a few years ago a skiing holiday provider promised a 30% discount to anybody named Sharon or Kevin. The idea was to make skiing holidays (traditionally associated with rich people) more appealing to working class folk (Kevin and Sharon are names more associated with said class in the UK).

I don't think this was ever challenged in a UK court, and wonder how it would have gone down. And if that would have changed if they discriminated the other way (offering the discount to people named Hugo or Spencer).

https://www.directski.com/shazandkev
and advertising flyer:
https://www.cheapflights.co.uk/news/wp-content/uploads/20...

Grsecurity goes private

Posted May 6, 2017 12:59 UTC (Sat) by CChittleborough (subscriber, #60775) [Link] (1 responses)

FWIW, RMS seems to be relying on 2 items from reddit which are in fact from April 2016, long before grsecurity made these policy changes. Hmm.

Grsecurity goes private

Posted May 6, 2017 13:08 UTC (Sat) by madhatter (subscriber, #4665) [Link]

That is not entirely surprising, as his comment is from mid-2016. Nevertheless, the posting that reports it (from Jun 2016) notes that "GRsecurity is preventing others from employing their rights under version 2 the GPL to redistribute (by threatening them with a non-renewal of a contract to receive this patch to the linux kernel.)", which looks to me exactly like the situation under discussion. So it looks to me like Grsecurity didn't decide this out of the blue, and RMS's comment was on the start of the process which they have now finished. I could be wrong, though.

Grsecurity goes private

Posted May 6, 2017 5:59 UTC (Sat) by citypw (guest, #82661) [Link] (3 responses)

Hi Jonathan,

With all due respect, I really appreciate you've been bring us high quality technical articles/reviews and the up-to-date conference/community news. Do you really believe what you wrote in this article? If that's what your thought, I think we may have very different philosophical ideas formed us into the different kind of ppl. Getting things upstream is good but "everything should be mainlined" is a religious faith. In case of PaX/Grsec, KSPP is a very good starting point but the fact I have to face in my daily life is there are "massive" exploitations in the wild can not be mitigated by the current version of KSPP. Who was the victim in those days of "one null-ptr deref exploit can rule them all"? Of course it's both community user and commercial users. Some commercial users even thought SELinux can help back in old days but we both know what really happened. Did RedHat ever made some compensation to RHEL users who paid? I don't think so. As a security consultant, I've been trying to avoid those "histories" from repeating in my life. Some ppl are taking the consequences of LF/CII's PR and I explained what I saw here:

http://openwall.com/lists/kernel-hardening/2017/05/04/10

btw, I still believe LF is zero integrity to me:

http://openwall.com/lists/kernel-hardening/2017/05/04/20

LF has different ways to treat different ppl. They treat you nicely maybe only because you are a reporter and they can get some benefit from your report. But most of ppl are just nobody and irrelevant to them. Btw, you didn't answer my previous question:

https://lwn.net/Articles/721253/

Are you seriously think they will talk to individual or small business?

Grsecurity goes private

Posted May 6, 2017 7:47 UTC (Sat) by niner (guest, #26151) [Link]

Jonathan said "there are ways of communicating serious answers to the right people at the LF". Those ways may just be different to the ones you seem to have tried.He may for example have meant, that if you tell him what the LF should have done differently, he himself would pass this information along to the right people at the LF. So your question may simply miss the point.

Grsecurity goes private

Posted May 6, 2017 11:35 UTC (Sat) by karkhaz (subscriber, #99844) [Link]

> Getting things upstream is good but "everything should be mainlined" is a religious faith.

Where did anybody say that "everything should be mainlined"? I think corbet was fairly balanced about this, pointing out that maintaining patches OOT is expensive, but that grsec have no obligation to upstream stuff if they don't want to.

Grsecurity goes private

Posted May 6, 2017 13:55 UTC (Sat) by corbet (editor, #1) [Link]

Yes, I believe what I wrote.

"Everything should be mainlined" does not appear in this article. But mainlining code is the best way to have a kernel that is coherent as a whole and maintainable going forward. Need I point out that, had all this code been upstream, your ability to make use of it for free in your role as a security consultant could not have been taken away from you by the grsecurity developers in this way?

I still don't understand why you think that a business decision made by the developers involved is somehow the Linux Foundation's fault. I'm known to be a slow person, so hopefully you'll understand if I just can't follow a couple of steps in the logic.

Grsecurity goes private

Posted May 6, 2017 21:50 UTC (Sat) by jgrip (guest, #95564) [Link]

I couldn't see anything in their FAQ on how they will deal with customers shipping grsec patched kernels. To not violate the GPL, they'd have to ship the source of the kernel or at least give on request. At that point it would be trivial to diff it against a pristine kernel and get the grsec patch set, not counting other vendor patches of course.

Would at a first thought make it next to unusable in sold products.

Grsecurity goes private

Posted May 8, 2017 5:56 UTC (Mon) by prasannatsm (subscriber, #109835) [Link] (1 responses)

Saying the move is because of 'business motive' looks like a opinion or judgement. Its strange to see such a thing from lwn. I feel sad about it. This is just my opinion, I may be wrong completely in saying so and I do not intend to hurt anyone or damage lwn's reputation in any way.

Grsecurity goes private

Posted May 8, 2017 9:58 UTC (Mon) by ber (subscriber, #2142) [Link]

Actually I like LWN's style of calling a thing that looks, swims and quacks like a duck a "most likely" duck. It allows to talk about a very likely impression that reasonable, calm and experienced people like Jon may have gotten. Yes, he fully brings in his experience, so there is a part of "judgement" in the article, which is good, because all articles include some of it, even reports. And having it explicit is better than the alternatives.

Grsecurity goes private

Posted May 8, 2017 8:31 UTC (Mon) by samth (guest, #1290) [Link] (1 responses)

I am very very far from having any side in this fight, but this article is, in my view, not up to the high standard that LWN sets for itself. Security is not an issue on which the kernel community has acquitted itself well over the past years, and it may be hard for our editor, a member of that community, to be hard on his fellow community members. However, this article reads like a brief for the defense, rather than a piece of reporting. An article that included the perspective of both sides, while also including some of the wisdom of our editor, would be the sort of thing I've come to expect (and continue to pay for) from LWN.

Grsecurity goes private

Posted May 8, 2017 10:59 UTC (Mon) by itvirta (guest, #49997) [Link]

I won't say anything about the standards of LWN, but any of the discussion I've seen about
grsecurity and Linux security in general (including here on LWN comments), has not been
up to what I consider the usual standards of civilized discourse between engineers looking
to solve a problem.

"More secure over time"?

Posted May 9, 2017 4:36 UTC (Tue) by ncm (guest, #165) [Link]

I could understand this as a ratio, as the sum of fitful improvements to security discounted by the relentless progress of time, but I doubt that was meant.

Yes, kernel code will be improved, but will the rate of improvement exceed that of the addition of new code? It seems unlikely. Since new security holes arrive in new code, while improvements generally target the most familiar code, the natural tendency of security, even with earnest effort, is not upward.

If the kernel community were to adopt rigorous standards and checklists to vet new code, the trend might be reversed, but I don't know what those would look like. Anyway it is absurd to think kernel developers would buy into what would be needed to actually be effective; and even that would be only part of a serious program.

Security weaknesses mostly arise as an accumulation of small weaknesses, each innocuous enough by itself. The kernelers have traditionally sneered at any weakness that was not a full exploit, all on its own, or anyway demonstrated to be a link in a complete exploit. That attitude is not compatible with getting or keeping a secure kernel.

So, they will muddle along, and we will make do, and console ourselves imagining how much worse it could be, and has been.

Grsecurity goes private

Posted May 11, 2017 1:35 UTC (Thu) by PaXTeam (guest, #24616) [Link] (4 responses)

if anyone's interested in more than another one-sided hit piece (one wonders who paid for this one...), read our response at http://www.openwall.com/lists/kernel-hardening/2017/05/11/2 .

Grsecurity goes private

Posted May 11, 2017 9:36 UTC (Thu) by jubal (subscriber, #67202) [Link]

…that above, old chap, is a serious accusation, and one that usually should be proven by the accuser; care to give us some facts (and I mean facts, not your usual happy excrement throwing routine)?

Grsecurity goes private

Posted May 11, 2017 9:50 UTC (Thu) by dunlapg (guest, #57764) [Link]

Finally, even if you can somehow disregard the thousands of upstream changes benefiting grsecurity[...]

what exactly benefits *grsecurity* (you know, what you defined as a kernel patch)[...]

I wish you could understand how this kind of thing completely undermines any credibility you might have. If you're either unable or unwilling to to comprehend the meaning of a simple and obvious sentence, how can I trust any characterizations or summaries you make about other people's statements or intentions in more complicated situations?

Who paid for it

Posted May 11, 2017 13:54 UTC (Thu) by corbet (editor, #1) [Link]

You remind me of my state's esteemed Republican senator, who likes to say that the people showing up at his town halls are paid by some shadowy entity to be there. For the record, LWN has never accepted payment to write or publish an article.

I read through the entirety of your response — took a while — but I don't really see that it addresses much that was said in this article.

Grsecurity goes private

Posted May 11, 2017 15:02 UTC (Thu) by jschrod (subscriber, #1646) [Link]

> one wonders who paid for this one...

Wow, this is *really* a new low...

And then you wonder, why some people don't want to work with you?

*Plonk*

Grsecurity goes private

Posted May 18, 2017 10:59 UTC (Thu) by ledow (guest, #11753) [Link]

The system appears quite simple to me.

- If grsecurity WANT it upstream, you have to play by upstream rules.
- If upstream WANT it, they will take the time/effort to take your code and change it to work by their rules.

But just saying "Hey, look, we fixed that problem but only in a way entirely incompatible with the kernel development / testing process, and we'll never upstream it" and then moaning that upstream are always "behind" is a bit petty. Especially when you have no interest in fixing the non-security problem in a random third-party PCIe hardware driver that's also coming in, and necessary, but which you then include in your works after upstream do that for you.

What's happened is actually the latter of the two scenarios - upstream take the security concerns on board, and would love a series of patches to fix it, but are effectively starting down the long road of duplicating all the effort involved on their own and without assistance because they're the only ones who actually want to play ball, and get the code into the kernel, and because it's many years down the line and nobody else has yet managed to pull anything back towards the kernel. And that's, quite clearly, a slower process to go through because it's NOT the only obligation on those people to pull in those patches, they have other things to do.

Ripping out, starting again, and doing everything your own way is quite obviously easier to do than working with a large project to get code accepted, as there's nobody to question, veto, convince or approve things like changing API or ABI, modifying the way critical functions work, or anything else.

The "extra work" of putting that stuff into the kernel seems to lead to the KSPP complaint too. "How dare they impose the same kernel submission processes on us as on every other developer, we're grsecurity, we should just get free reign and our all-ranging code modifications pulled in without question." And with security, that worries me.

Someone has to take the time and effort to pull security changes into the kernel. The larger and more wide-ranging the change, the harder the work and the longer it takes. The kernel people can do it. But it will be slow as they have other stuff to do and take account of. The grsecurity people could do it. But they don't, despite it being their biggest concern, most vocal complaint and their "only job" (in effect) is to get security code that works with the kernel.

And it seems to be because they cannot work to anyone else's requirements whatsoever, or discover a third-party who's willing to work with both sides to do the work. There are thousands of companies contributing to the kernel, and lots of "go-betweens" because the most horribly-closed of commercial projects and the open kernel processes. But not one can be found to negotiate the middle ground between the kernel and grsecurity.

To me, that doesn't bode well for any kind of development. Especially security-related development that requires discussion, is likely to break user experiences, touches on every part of the kernel, may well require quick fixes at critical moments, and which everyone has to understand if it's to work properly.

We seem to always be in this same circle with grsecurity, and I'm not at all sure that we aren't benefiting from that stalemate.

If this code was in-kernel, and grsecurity had everything they needed inside the kernel, and they were working on new defences, we'd still end up with the same conversation again for those. And, presumably, for updates of any new grsecurity patch, bugfix or whatever as it needs to be pulled back into the kernel.

And when there's no end in sight because of not following the process, the code is effectively dead from a kernel point of view.

Grsecurity goes private

Posted May 19, 2017 14:26 UTC (Fri) by sergey (guest, #31763) [Link] (6 responses)

KSPP clearly claim they're fixing (or "fixing," depending on who's talking) grsecurity as part of their work, hence they admit to doing upstreaming rather than just borrowing ideas. The authors of the code want to port patches on their terms and get paid for it, and their estimate of thousands of hours doesn't seem far off the mark so we're talking about a potential commitment of a ~$1M here. There's an obvious conflict because whoever is sponsoring this chose KSPP developers, a 3rd party, and not the authors. Good journalism would be to follow this money and get to the bottom of such decision.

> Paying for work on free software, intended to improve the security of the Linux kernel, does not seem like a particularly blameworthy activity, so it's not entirely clear why the Linux Foundation is being faulted here.

Grsecurity is the author of the work and they claim they don't get any of these payments.

> There is a much more likely explanation here: the movement of hardening features into the mainline kernel poses challenges to the developers' business model, which depends on providing security features not found there.

Their business model is not far different from any antivirus vendor and hinges on the kernel's and attackers' constant evolution. What can take it away is if attackers stopped inventing exploits or Linux stopped releasing new versions. Hardening patches are result of their very specialized, and highly regarded, expertise. Grsecurity doesn't appear to excel at interpersonal relations and this move is clearly to spite the community for diverting compensation they thought they deserve (correctly, I think) and has little to do with what their clients pay them for.

Grsecurity goes private

Posted May 19, 2017 15:07 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

KSPP clearly claim they're fixing (or "fixing," depending on who's talking) grsecurity as part of their work, hence they admit to doing upstreaming rather than just borrowing ideas. The authors of the code want to port patches on their terms and get paid for it, and their estimate of thousands of hours doesn't seem far off the mark so we're talking about a potential commitment of a ~$1M here. There's an obvious conflict because whoever is sponsoring this chose KSPP developers, a 3rd party, and not the authors. Good journalism would be to follow this money and get to the bottom of such decision.

Are you seriously suggesting that wanting security improvements without having to deal with the grsecurity developers' charming personalities is so suspicious that a financial investigation should be launched? If security were being worsened you might be right, but I don't think security improvements (that grsecurity has been loudly lauding for years) are exactly a sign of corruption or malfeasance, any more than performance improvements or support for new hardware are.

Why aren't you also proposing that everyone who works on the scheduler have their financial backing investigated? What about new filesystems? Lustre is really suspicious, you know, it's obviously being funded by disk manufacturers to increase demand for their drives! (... which might indeed be part of the motivation, but increasing demand for your drives by making better filesystems that can use big collections of drives better is, again, not suspicious, but actually good customer service which should be encouraged.)

Grsecurity is the author of the work and they claim they don't get any of these payments.

Given that they have explicitly refused to accept payment from any of the bodies willing to pay for it, this is not particularly surprising nor a sign of anything but obstreporousness on the part of the grsecurity developers.

Grsecurity goes private

Posted May 21, 2017 17:05 UTC (Sun) by flussence (guest, #85566) [Link]

> Given that they have explicitly refused to accept payment from any of the bodies willing to pay for it, this is not particularly surprising nor a sign of anything but obstreporousness on the part of the grsecurity developers.

I have to wonder, but I'm not particularly interested in an answer: who *is* going to pay them now?

Their product is now behind a paywall so the little people can't use it, and they punish large orgs who *could* afford it by killing the contract if they “leak” the source and charging costs to reinstate it reminiscent of RIAA lawsuit plea bargains.

If you're actually a FOSS-friendly company, as opposed to a scummy TiVo/Allwinner type, there's no reason to use or fund grsec because they've stated plainly they will screw you for daring to comply with the letter and spirit of the kernel's GPL.

Following the money

Posted May 19, 2017 15:21 UTC (Fri) by corbet (editor, #1) [Link] (3 responses)

"If a financial arrangement is desired, I believe my employer continues to be willing to explore it now just as they have in the past."

— Kees Cook, May 11

Following the money

Posted May 21, 2017 21:40 UTC (Sun) by PaXTeam (guest, #24616) [Link] (2 responses)

repeating lies over and over again won't make them true all of a sudden. of course if that's what your 'sponsors' desire then at least stop pretending to be an unbiased observer that presents more than one side of the coin (oh wait, you did not). reminds me, how's my contributions to the kernel-hardened list since the beginning of the KSPP corroborate your theory of me being afraid of their impact on grsec's business?

Following the money

Posted May 22, 2017 11:45 UTC (Mon) by flussence (guest, #85566) [Link]

Spitting in the face of people who can decide whether or not your company makes any future sales and shooting the messenger in public seems an unwise business strategy.

Maybe your only purpose is to serve as a warning to others.

Following the money

Posted May 23, 2017 14:58 UTC (Tue) by bronson (guest, #4806) [Link]

There's a bit of substance in there but it's drowned out by paranoia and bile. Maybe you could hire someone to handle communications?