No more grsecurity test patches [LWN.net]

The grsecurity project has announced that its kernel-hardening patches will now be an entirely private affair. "Today we are handing over future maintenance of grsecurity test patches to the community. This makes grsecurity for Linux 4.9 the last version Open Source Security Inc. will release to non-subscribers."

to post comments

No more grsecurity test patches

Posted Apr 26, 2017 16:49 UTC (Wed) by jhoblitt (subscriber, #77733) [Link] (55 responses)

grsecurity.net seems to be down... How does this new strategy comply with the GPL?

No more grsecurity test patches

Posted Apr 26, 2017 16:53 UTC (Wed) by farnz (subscriber, #17727) [Link] (26 responses)

I'd guess that they'll be invoking clause 3.a, and supplying full source to anyone they ship the patches to, and give you the right to redistribute. Thus, if you really want to, you can play the cat-and-mouse game of subscribe, ship current hardening patches to community, get your subscription revoked and repeat under a new business identity.

No more grsecurity test patches

Posted Apr 26, 2017 21:42 UTC (Wed) by Sesse (subscriber, #53779) [Link] (23 responses)

On what grounds would the subscription be revoked? I mean, you can't have in your subscription terms “don't distribute the [GPLed] patches”.

Do-not-distribute terms

Posted Apr 26, 2017 21:50 UTC (Wed) by corbet (editor, #1) [Link] (22 responses)

A subscription can have exactly those terms; grsecurity would be far from the first to use them. You can't forbid redistribution, but you can terminate the contract if redistribution happens. I remember that even Richard Stallman has said that such terms are legitimate, though I can't find the reference now.

Do-not-distribute terms

Posted Apr 26, 2017 21:59 UTC (Wed) by Sesse (subscriber, #53779) [Link] (21 responses)

So you'd get software both under the terms of the GPL, saying you have the right to redistribute, and at the same time, a different contract saying you can't redistribute? It would make for an interesting day in court to see if the latter would hold up or be struck down as in conflict with the GPL (as additional restrictions).

Do-not-distribute terms

Posted Apr 26, 2017 22:09 UTC (Wed) by corbet (editor, #1) [Link] (20 responses)

Again, the contract doesn't say "you can't redistribute". It says "if you redistribute, we won't give you any more in the future". It's an important distinction.

Do-not-distribute terms

Posted Apr 26, 2017 22:22 UTC (Wed) by corbet (editor, #1) [Link]

(Although, as Arjan just pointed out, punishing redistribution is likely to be a hard sell in this particular case; it's not quite like, say, an enterprise Linux subscription.)

Do-not-distribute terms

Posted Apr 27, 2017 9:48 UTC (Thu) by epa (subscriber, #39769) [Link] (16 responses)

The point is that any "if you redistribute..." clause in the contract is a restriction on redistribution. Even, "we will pay you ten dollars every month, but if you redistribute, we'll stop". In the end, what is the difference between such agreements and "if you redistribute, we will sue you in court"?

I don't know what the legal theory is here but to a layman it seems clear that if you may not restrict someone's right to redistribute, then you may not threaten them with consequences for exercising that right. In the USA a law which said "you have the right to free speech, but if you exercise it, then you will lose certain welfare payments" would be struck down as unconstitutional.

Do-not-distribute terms

Posted Apr 27, 2017 11:22 UTC (Thu) by dsommers (subscriber, #55274) [Link] (15 responses)

IANAL, but there are two "contracts" involved here.

1) the GPLed source code. That allows redistribution. No one argues about that.
2) The subscription agreement. That can say: "If you redistribute the code, we will not give you any further updates". Which in effect is a cancellation of the subscription agreement.

Yes, the subscription agreement reduces your freedom as a consumer of the code in regards to the future updates. But they can still argue that you are free to share the GPLed code. You're just punished differently if you do so.

The challenge here is that the subscription provider is free to do whatever they want with you as a subscriber, as defined in the independent subscription agreement. To have a valid subscription with regular updates, you cannot break that subscription agreement. But regardless of what the subscription agreement says, you are allowed to do whatever you want with the code you receive in the updates (in accordance to the license of the code). The snag is the "punishment" the subscription agreement may carry when using your freedom.

So in my point of view, this is a lock-in subscription agreement.

But real question is if someone is able to find a way to argue that the subscription agreement is an unlawful restriction of the GPL. That's not going to be an easy task. As a layman, it is easy to see the consequences, but that doesn't mean the legalese makes it illegal.

It is anyway a dirty game they've started. I somewhat understand the reasoning behind it, but I don't agree to this approach.

Do-not-distribute terms

Posted Apr 27, 2017 12:04 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> It is anyway a dirty game they've started. I somewhat understand the reasoning behind it, but I don't agree to this approach.

It's also close to the model that RedHat takes with RHEL. Redistribution of binaries will get your subscription yanked, but you're still technically free to do so. Where it differs is that RH freely posts the source packages for anyone to rebuild.

Do-not-distribute terms

Posted Apr 27, 2017 12:48 UTC (Thu) by dsommers (subscriber, #55274) [Link]

It is somewhat related. But there are a few very important differences as well.

The source code to all the RPMs are made available (basically via the CentOS repositories and http://git.centos.org/)
You can download the binary install medium directly from the Red Hat, including binary RPMs free of charge. But you will not have the updated packages, only the ones shipped in the install medium for each point-release. Yes you need to register, but that does not cost any thing.
And there is nothing in the GPL which says the binary packages must be made available. It generally talks about the source code and building instructions (which .spec files in .src.rpms essentially is). RHEL consists of packages using more licenses as well, but GPL is one of the more commonly restrictive ones in use, so that's why I'm focusing on that.

The issue with grsec is that they impose a somewhat implicit restrictions on distribution of the GPLed source code, That is not happening with RHEL. With RHEL/CentOS source packages you get distributions like Scientific Linux.

And another not that related detail: "Developers can now get a no-cost Red Hat Enterprise Linux® Developer Suite subscription for development purposes by registering and downloading through developers.redhat.com." (source) .... You'll get the full rolling updates through a valid subscription, without any cost - but it is not permitted to be used on production servers and such.

Do-not-distribute terms

Posted Apr 27, 2017 14:23 UTC (Thu) by epa (subscriber, #39769) [Link] (12 responses)

But real question is if someone is able to find a way to argue that the subscription agreement is an unlawful restriction of the GPL.

It's hard to see how it could be held to be compatible with the GPL without making the GPL entirely unenforceable. Since anyone could then distribute GPL'd software subject to signing a "contract" which says you agree not to redistribute it, not to alter the source code, to pay for per-CPU licences, and so on.

Red Hat gets away with what they do since they publish all the source code, and people aren't so exercised about redistributing binary executables built from that source. But legally, I think, both a binary executable and a modified version of the source are derived works. If they can stay within the letter of the GPL yet restrict redistribution of binaries, then they can do the same with source code. And if Red Hat can do it, anyone can.

Do-not-distribute terms

Posted Apr 27, 2017 14:51 UTC (Thu) by farnz (subscriber, #17727) [Link] (11 responses)

Ah, but the subscription contract does not restrict what you do with the GPL'd code, beyond the restrictions in the GPL; instead, it says that if you choose to exercise your rights, then the subscription contract is terminated. So it's completely compatible - you can distribute anything that you've received under GPL, but if you do so, the company providing you services will stop doing so in future; the contract does not override the GPL, it just says that if you exploit your GPL rights, you lose your contract benefits, too. As you want to keep those contract benefits, you won't exploit your GPL rights - but it's those contract benefits that are withdrawn, not your GPL benefits.

Do-not-distribute terms

Posted Apr 28, 2017 11:16 UTC (Fri) by epa (subscriber, #39769) [Link] (10 responses)

That's exactly my point. It says that if you exercise your rights under the GPL, then... (insert consequence here). If this is compatible with the GPL then it's hard to see how the GPL can be enforced at all in practice. You could receive a copy of gcc subject to a contract which says you can modify the source code, but if you do so then you agree to pay $1000 in licensing fees for each line of code changed. (Or upon payment of a sum upfront, which is then refunded in part each month depending on your compliance with the conditions.) And so on.

The GPL (version 2) says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." If that is to have any meaning at all, it must mean that you may not impose consequences on recipients who exercise those rights, or put them on a "naughty list" depending on whether they do so.

If not, you can get round any requirement not to impose restrictions. Congress may make no law restricting freedom of speech but it could quite easily raise taxes and then pay everyone a tax rebate conditional on whether they keep quiet. After all, it is just the extra tax rebate that is withdrawn, not your right to free speech...

Do-not-distribute terms

Posted Apr 28, 2017 12:34 UTC (Fri) by dsommers (subscriber, #55274) [Link] (9 responses)

«The GPL (version 2) says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." If that is to have any meaning at all, it must mean that you may not impose consequences on recipients who exercise those rights, or put them on a "naughty list" depending on whether they do so.»

But that is the crux of it all. The freedom on the GPLed software isn't restricted in these scenarios. You are absolutely free to do what you want with that software. But the relation to a service provider who provides a distribution channel for the GPLed code, will also have an independent contract where conditions for the service is defined. If one of the parties violates that independent contract, that have consequences for the service and not the software itself.

Which means, you as a customer will have a different customer experience with the service provider if do not violate the service agreement vs if you violate the agreement.

In the Red Hat case, IMO, they are on the right side. There are no restrictions put on the source code and it is freely available through the channels Red Hat have chosen. There exists no software without a source code of some kind. If you choose to redistribute the source RPMs, you are free to do so under the same conditions the license of the source code is based upon. This should further not cause any implications to the services you have subscribed to with Red Hat.

It is tempting to consider the argument that a binary version of a source code being a derived work. IANAL, but I believe that is a misinterpretation of «derived work». My understanding of derived work is that you have made a new software with a modified functional behaviour, where you have based these changes on an existing code base. Since it is also possible (though it will demand quite some efforts) to build basically an identical binary - from a functional context - based on the source code, then it is not a derived work. What will differ is timestamps saved into the binary files, which causes no functional difference - hence no derived work. This rebuild may be redistributed without any restrictions and it should not violate any service agreement with Red Hat. It is not their object code or executable result you distribute.

There is also nothing in the GPL which demands that the compiled (binary) result (object code or executable form) of a software must be made available. But it goes all the way to state that the source code used to create the object or executable code must be made available if you distribute the object code or executable result. And you may not impose any additional restrictions on that source code if being redistributed.

In the gresec case it is quite different. They seem to provide a restriction on what you can do with the source code if you want to make use of their service. Since, IMO, the GPL is focused on the source code, this tangents the issue you found in the GPL. However, they can probably go free from this too. As grsec will then cancel the service agreement you have with them, but will not restrict you from exercising your rights on the code itself as defined in the GPL. Whether this holds in court or not, entirely depends on the legalese in the service agreement you have with grsec. Not how the GPL is interpreted. It might be possible to argue that such a clause of the service agreement don't hold water because it restricts a freedom you have been granted in the products license you have received via this service agreement. But again, that all comes down to the wording and interpretation of the service agreement, not GPL itself. Regardless, the consequences of breaking the service agreement with grsec is a different customer experience with grsec, not the GPLed code.

Do-not-distribute terms

Posted Apr 28, 2017 14:13 UTC (Fri) by PaXTeam (guest, #24616) [Link] (7 responses)

> There are no restrictions put on the source code and it is freely available through the channels Red Hat have chosen.

are you saying that things have changed back since https://lwn.net/Articles/430098/ ?

also this:

> [grsec] seem to provide a restriction on what you can do with the source code[...]

vs.

> [grsec] will not restrict you from exercising your rights on the code itself as defined in the GPL.

confuses me. are we restricting 'what you can do with the source code' or not? ;)

Do-not-distribute terms

Posted Apr 28, 2017 15:10 UTC (Fri) by dsommers (subscriber, #55274) [Link] (6 responses)

> > There are no restrictions put on the source code and it is freely available through the channels Red Hat have chosen.

> are you saying that things have changed back since https://lwn.net/Articles/430098/ ?

Nope. And the kernel source code which is used to build RHEL kernel packages is fully available today as it was back then.

>> [grsec] seem to provide a restriction on what you can do with the source code[...]
>
> vs.
>
>> [grsec] will not restrict you from exercising your rights on the code itself as defined in the GPL.
>
> confuses me. are we restricting 'what you can do with the source code' or not? ;)

Well, when you cut out half the sentence, it gets confusing. By adding the missing part, it helps:

« [...] if you want to make use of their service.»

Do-not-distribute terms

Posted Apr 28, 2017 18:42 UTC (Fri) by PaXTeam (guest, #24616) [Link] (5 responses)

> Nope.

are you saying that they would still terminate the support contract if a customer publicly redistributed their kernel source code in the form of individual patches? if so then why did you claim that there were "no restrictions put on the source code"?

> By adding the missing part, it helps:

it does not which is why i justapoxed your two contradicting statements that both talked about our service. first you claimed restrictions on the *source code* (emphasis by you) then you claimed that there weren't any. which is it then? and once you also answer the above question, why is RH's 'restriction' on the right side whereas ours isn't?

Do-not-distribute terms

Posted Apr 28, 2017 21:18 UTC (Fri) by dsommers (subscriber, #55274) [Link] (4 responses)

> are you saying that they would still terminate the support contract if a customer publicly redistributed their kernel
> source code in the form of individual patches? if so then why did you claim that there were "no restrictions put on
> the source code"?

There are *no* restrictions on the source RPMs which are used to build the kernel RPM. That is what I claim. There is nothing in the GPL anywhere which defines the format or granularity of how the source code is to be distributed. It just says the source code used to produce object code or executable format is to be made available.

The customer portal may have (I have not used it, only heard claims that it exists) a source code browser. How the source code is presented is unknown to me, is not relevant to me. To me the full, unrestricted access to the source code which produces the binary RPMs is my interest point. That source browser is a service which have its own EULA. The EULA you can read for yourself here: https://access.redhat.com/help/terms/ ... And this *service* may have restrictions to how you use the *service*. That does not imply that there is a limitation to what you can do with the GPLed code put inside a source RPM.

> it does not which is why i justapoxed your two contradicting statements that both talked about our service. first you claimed restrictions on the *source code* (emphasis by you) then you claimed that there weren't any. which is it then?

The kernel source code is GPLed. If you ship a derived work of the kernel (which I consider the grsec patchset to be), it must be GPLed - according to the GPL license. So I ask you instead: What happens if one of your users redistribute that derived work?

> And once you also answer the above question, why is RH's 'restriction' on the right side whereas ours isn't?

Because Red Hat does not restrict redistribution of the source code used to build the binary RPMs. The source RPMs are fully and freely available, no strings attached, no limitations imposed - as long as you follow the license of the source RPM. Again, that source RPM is what is needed to build the binary RPMs you install on your system.

Do-not-distribute terms

Posted Apr 28, 2017 22:50 UTC (Fri) by PaXTeam (guest, #24616) [Link] (3 responses)

> There are *no* restrictions on the source RPMs[...]

you're changing the subject now as you made claims about generic 'source code' before not just SRPMs. this makes no sense to me since you were comparing "the Red Hat case" (of tying their service to customers' not exercising their rights to redistribute broken out kernel patches, not SRPMs) to our case. why you keep bringing up SRPMs which are unrestricted (AFAIK) is beyond me, that's not at all the subject of the discussion. but if you want to go with the SRPM case, let me ask you this: what will happen if a customer replaces the monolithic patch in the kernel SRPM with the broken out series and redistributes that? are they permitted to do it? does Red Hat terminate their contract?

> And this *service* may have restrictions to how you use the *service*.

if you read the EULA you linked to it says in the 'Term and Termination' section that:

> Your right to access Red Hat Content expires automatically when you no longer have valid subscriptions for Red Hat products.

now my understanding is that you lose that subscription (and thus access to the portal) when you redistribute the broken out kernel patches. your 'nope' seems to have confirmed to me that it was your understanding as well. do you agree with this or did you mean something else? if you agree then you can't claim that there're no restrictions on the source code as clearly some form of it is restricted (which happens to be very important if you're interested in more than mere recompilation, see the original LWN article).

> > first you claimed restrictions on the *source code* (emphasis by you)
> > then you claimed that there weren't any. which is it then?
> The kernel source code is GPLed.[...]

this doesn't answer my question at all. so one more time: do you claim that we put restrictions on the *source code* or not? yes/no please. if yes, do elaborate as i'm sure some kernel copyright holders will want to know about it.

> What happens if one of your users redistribute that derived work?

it entirely depends on their contract (which i'm not privy to as it's Brad's business, not mine), but you can always negotiate one and you'll see the terms.

> The source RPMs are fully and freely available, no strings attached, no limitations imposed - as long as you follow the license of the source RPM.

no limitations imposed? so my question above reduces to this: does a customer have the right to replace the monolithic kernel patch with the broken out series in the kernel SRPM? assuming yes, do they have the right to redistribute that SRPM? assuming yes, what will Red Hat's response be? will they terminate the support contract or not?

Do-not-distribute terms

Posted Apr 29, 2017 0:32 UTC (Sat) by dsommers (subscriber, #55274) [Link] (2 responses)

> but if you want to go with the SRPM case, let me ask you this: what will happen if a customer replaces the monolithic patch in the kernel SRPM with the broken out series and redistributes that? are they permitted to do it? does Red Hat terminate their contract?

I can not give an authoritative answer here, as I am in no position or role to represent Red Hat and their view points. But if you put the efforts of splitting up that patch by finding the relevant commits in Linus' kernel git tree and making it build ... As a layman, I see no reason why that should cause an issue if you redistribute that. But IANAL and neither a Red Hat representative. So you will have to ask them or a lawyer.

But I struggle to see why the patching Red Hat does is so important to you. GPL does not impose any preferred format, granularity of how to come to a certain result. All the GPL says is that the source code must be made available, which Red Hat does through their SRPM files. If SRPM is an issue for you, you can extract the cpio archive inside it and unpack the tar ball and build the pieces together manually. And you can redistribute that source code freely without any restrictions and fear of implications - as long as you stay aligned with the license of the source code.

> this doesn't answer my question at all. so one more time: do you claim that we put restrictions on the *source code* or not? yes/no please. if yes, do elaborate as i'm sure some kernel copyright holders will want to know about it.

I honestly don't know if you put restrictions or not. If looking purely at the source code and only on that, you basically are not allowed to do so by the GPL, so I hope you are not doing that. But looking at it in a broader context, it is really not clear to me at all if the end result is a restriction or not. Which is why I asked what would happen if one of your customers would do just that; to gain a better understanding.

The reason is that there might be someone being willing to argue (most likely lawyers) that *if* there are some kind of negative consequences by distributing your derived work, you are _implicitly_ revoking a freedom initially provided by the GPL license. But that is purely a speculation from my side.

And that scenario is really not comparable at to what Red Hat does. Because they do provide the complete source code used to build the object and executables used on a system, without any restrictions using their preferred distribution format (yes, SRPM) - thus Red Hat users and customers don't need to fear what could happen later on if they redistribute that source code. But you seem to try to twist that into that Red Hat is obliged to provide the granular development process of that source code, while the GPL does not and have never required that.

Do-not-distribute terms

Posted Apr 29, 2017 8:35 UTC (Sat) by PaXTeam (guest, #24616) [Link] (1 responses)

> I can not give an authoritative answer here [...]

then why did you say that the Red Hat kernel patch situation discussed in the LWN link i gave you has not changed since? do you know what that situation is at all?

> But if you put the efforts of splitting up that patch by finding the relevant commits in Linus' kernel git tree [...]

that is not at all the Red Hat situation so i'm not sure what you've been discussing all along. what did happen was simple: Red Hat used to put a kernel patch series into their kernel SRPM instead of one big monolithic patch or a fully pre-patched tree. both satisfy the GPL but they aren't equivalent in other ways. then one day Red Hat decided to replace the patch series in their kernel SRPM with a monolithic patch (or a pre-patched tree, doesn't matter) *and* stop distributing their kernel patch series to the geneal public. instead, they made that series available to their paying customers only *and* changed their service terms to 'restrict' (your term, not mine) the distribution of that source code (again, your terms): they stipulated that it'd be a breach of those terms (and thus result in service termination) if the customer did distribute that patch series to non-subscribers ('source code'). you said that this 1. was fine for 'the Red Hat case', 2. is not a restriction on that source code, 3. is a restriction on our source code if we did this, 4. thus it's not ok for us to do this. that is a contradiction there that you have yet to resolve.

> I honestly don't know if you put restrictions or not.

vs.

> They seem to provide a restriction on what you can do with the source code if you want to make use of their service.

so do you know something or do you not know something?

> But you seem to try to twist that into that Red Hat is obliged to provide the granular development process of that source code[...]

i did not say that at all, quite the contrary in fact. what you did say was however that it was fine for Red Hat to terminate their support contract if a customer redistributed their broken out kernel patches ('source code' in your terms) but it is not fine for us to do the same. you haven't addressed this contradiction so far.

Do-not-distribute terms

Posted Apr 29, 2017 17:01 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Are you saying that your customers can redistribute the non-broken out patches for grsecurity? Without consequences for their subscription? If so, I see no contradiction here. If you had a "higher ground" to argue from about the single-patch versus broken-out-patches that Red Hat does, I can see why you'd argue about this, but I see more fundamental issues here.

Do-not-distribute terms

Posted Apr 30, 2017 10:31 UTC (Sun) by Wol (subscriber, #4433) [Link]

> It is tempting to consider the argument that a binary version of a source code being a derived work. IANAL, but I believe that is a misinterpretation of «derived work».

IANAL too, but (time stamps etc excepted) as a mathematician I would actually argue that the source and binaries are the SAME work.

Failure to understand this point by the legal system is part of why the legal protection of software is such a mess ... :-)

Cheers,
Wol

Do-not-distribute terms

Posted Apr 27, 2017 13:55 UTC (Thu) by Sesse (subscriber, #53779) [Link] (1 responses)

Well, does “we won't give you any more in the future” mean you also get your money back for the remainder of the contract?

Do-not-distribute terms

Posted Apr 27, 2017 18:51 UTC (Thu) by mikemol (guest, #83507) [Link]

Only if the contract (or applicable law) stipulates that contract cancellations get pro-rated refunds. But that's not exactly common...

No more grsecurity test patches

Posted Apr 26, 2017 22:12 UTC (Wed) by arjan (subscriber, #36785) [Link] (1 responses)

revoking subscriptions is not a practical thing. A commercial customer would most likely like to ship products with the code in it, and that means that customer is required to comply by the GPL and give the code out... banning that upfront will causing many companies not even consider the thing in the first place.

No more grsecurity test patches

Posted Apr 27, 2017 5:39 UTC (Thu) by thestinger (guest, #91827) [Link]

Their commercial partners are almost entirely using it on servers. Internal client usage also doesn't present a problem. Only a grsecurity customer shipping products to their own customers hits a major snag but it's not clear if they actually have any customers like that.

No more grsecurity test patches

Posted Apr 26, 2017 17:15 UTC (Wed) by flussence (guest, #85566) [Link] (27 responses)

How does it comply with security best practices, for that matter?

Last time they got outside code review, instead of thanking the contributor they had a complete meltdown in public and disabled their twitter account. These people care more about stroking their egos than the quality of their work.

No more grsecurity test patches

Posted Apr 26, 2017 18:13 UTC (Wed) by vadim (subscriber, #35271) [Link]

Do you have a link to this code review?

Long ago, I tried the patches and ran into a kernel panic in grsecurity code. I did some cursory research with the few skills I had at the time, and was quite unimpressed by the end of it. I'm wondering if things have gotten better since then, or they're still the same.

No more grsecurity test patches

Posted Apr 26, 2017 18:22 UTC (Wed) by nix (subscriber, #2304) [Link]

I don't know. How does finding exploits and posting an MD5 hash of them to prove you were first, then not revealing the exploit to anyone, including upstream, comply with security best practices? (Something they have not only done but done *in LWN comment threads*). These people really *do* care more about getting credit than security.

No more grsecurity test patches

Posted Apr 26, 2017 18:52 UTC (Wed) by imitev (guest, #60045) [Link] (9 responses)

You're always quick to comment on grsec news with a very critical stance.

I've always been happy with the grsec -stable patch and quite a few security conscious companies/individuals use it so I'd be genuinely interested why you're so negative, save for not liking the guys' egos/personality as those have nothing to do with the code's quality and if it gets the work done/improves security. Can you point to code review(s), criticism of grsec security mitigation measures, ... ?

No more grsecurity test patches

Posted Apr 26, 2017 19:31 UTC (Wed) by Conan_Kudo (subscriber, #103240) [Link] (7 responses)

But their personalities have everything to do with code quality. Because of how they are as people, they refuse to allow their code to have greater scrutiny. In addition, they are unwilling to work with the upstream Linux kernel community to help gradually integrate the patch set so that the security features can be available to everyone. They get offended easily by people externally reviewing it and offering criticisms of the code, and when someone finds a vulnerability, they handle it really badly. This means that they live in an echo chamber, and there's no regular vetting of their changes to ensure that it actually does what it says on the tin reliably and properly. Time and time again, I see people say things like "it doesn't matter how they are as people, as long as the code is good." That's not how this works. Free Software/Open Source Software, at the core, is all about collaborating to come up with the best solutions I wouldn't trust them with a toaster, much less my desktop or my servers.

No more grsecurity test patches

Posted Apr 27, 2017 7:55 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link] (4 responses)

> Because of how they are as people, they refuse to allow their code to have greater scrutiny.
Er... Until the change which prompted this thread, they've been distributing their patch in the open *for 16 years* ! Would you be so kind as to explain me how that's "refus(ing) to allow their code to have greater scrutiny" ?

> In addition, they are unwilling to work with the upstream Linux kernel community to help gradually integrate the patch set so that the security features can be available to everyone.
You're having it backwards, like about almost everybody else: upstream is well known to flat out refuse a number of powerful defenses from PaX/grsecurity for entirely bogus reasons, and is even proud of it. On that topic, look for Linus' public statement about having refused UDEREF in the past being a good thing, because "the hardware does it". Not only this is technically wrong, as repeated time and again by PaXTeam (PaX is a strict superset of SMAP - and it was not subject to multiple serious vulnerabilities in the mainline SMAP support, BTW), but also, Linus' stance does nothing useful for e.g. the ~billion x86/x86_64 systems around for 30+ years which do not provide such a hardware feature.
I remember commenting about that on LWN; Linus' aforementioned statement was the event which made me truly understand that mainline Linux security is a completely lost cause... I did upstream several minor hunks of PaX/grsec in the past, I gave up for that reason (combined with other reasons on my side, let's be honest).
Also, "gradually integrat(ing) the patchset" is what the KSPP does. Its slow efforts are hampered by mainline's counter-productive stance about security, look for yourself at https://grsecurity.net/compare.php : all the KSPP can achieve is to integrate a watered down version of a small subset of PaX/grsec's security mechanisms, from which 3 of the main 5 defenses (MEMORY_UDEREF, KERNEXEC, CONSTIFY, RANDSTRUCT, RAP) are missing and will "never" be integrated.

So... given roadblocks of such strength, why exactly would PaXTeam, spender and ephox be willing to spend part of their free time working _directly_ on mainline integration _on a regular basis_, when they know, from past facts, that the end result, after time-consuming bikeshedding, is going to be crap ? They tried to upstream at least one isolated subset of their work in the past, look for the attempts to mainline the constification work, before PaX switched to a plugin.
They've already got more than enough work on their plate reviewing and fixing upstream work (which is an indirect form of working for mainline, BTW), as well as adjusting PaX/grsecurity after the little that came out of the KSPP's efforts caused significant conflicts with their work. The work of adjusting code after mainline botched it is made even more unpleasant by the reduction in security benefit caused by mainlining through the KSPP...

> They get offended easily by people externally reviewing it and offering criticisms of the code,
I've seen that occur for other persons, but spender and PaXTeam have been kind to me when I reported several minor issues over time.

> and when someone finds a vulnerability, they handle it really badly.
We do agree on that, though. spender botched the handling of Hector Marco's report, for instance. Even if Hector Marco himself could have used better wording, to sound less like he was trying to do a public splash.

> I wouldn't trust them with a toaster, much less my desktop or my servers.
Oh, now I get you're trolling :)
Here's a little secret for you: despite the errors, which they fix quickly (more so than mainline), the code quality in PaX/grsec is higher, from a security attention POV, than in mainline.

No more grsecurity test patches

Posted Apr 28, 2017 16:31 UTC (Fri) by luto (subscriber, #39314) [Link] (2 responses)

> multiple serious vulnerabilities in the mainline SMAP support, BTW

And those vulnerabilities are?

> all the KSPP can achieve is to integrate a watered down version of a small subset of PaX/grsec's security mechanisms, from which 3 of the main 5 defenses (MEMORY_UDEREF, KERNEXEC, CONSTIFY, RANDSTRUCT, RAP) are missing and will "never" be integrated.

Why not?

No more grsecurity test patches

Posted Apr 28, 2017 20:12 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link] (1 responses)

> And those vulnerabilities are?
From the first page of my Google search results for "Linux SMAP bypass": a thread about one of them was started on oss-sec ( http://seclists.org/oss-sec/2016/q1/446 ) by "luto". The real-world impact of that "bug that exposed a fairly large kernel code surface to a straightforward SMAP bypass" was low because SMAP-capable hardware was scarce back then (and it still is, a year later), but before that bugfix, the SMAP support in Linux never worked safely.
Granted, the first few result pages for "Linux SMAP bypass" and "Linux SMAP defeat" queries do not seem to return other SMAP bypasses *in SMAP code*. The DirtyCOW exploit and a Xen exploit bypass both SMEP and SMAP.

> Why not?
* for MEMORY_UDEREF and KERNEXEC, because Linus refuses to. From the KS 2015 report: https://lwn.net/Articles/662907/ + my comment there linking to older LWN comments by PaXTeam and spender. I can't imagine Linus changing his mind since then: https://lwn.net/Articles/705262/ , from less than 6 months ago, reports that he stated that "he hates the emulation patches with a passion";
* for RAP, because a prerequisite is integrating into mainline, in small pieces (large, intrusive patches don't get in), the fixes made in PaX, mainly by PaXTeam AFAIK, for the thousands of instances of bad fptr casts. That's a huge amount of work, and it produces no functional effect on the mainline kernel (which works as is)... so even if such patches weren't likely to be turned down on the grounds that they have no effect on a mainline kernel, who's going to fund that work ?

No more grsecurity test patches

Posted May 2, 2017 16:20 UTC (Tue) by luto (subscriber, #39314) [Link]

> From the first page of my Google search results for "Linux SMAP bypass": a thread about one of them was started on oss-sec ( http://seclists.org/oss-sec/2016/q1/446 ) by "luto".

So the upstream SMAP implementation had a bug. That doesn't mean that UDEREF is inherently superior -- it meant that the upstream SMAP implementation had a bug.

> he stated that "he hates the emulation patches with a passion";

I wouldn't be at all surprised if someone writes a variant that Linus accepts in the next year or so.

> so even if such patches weren't likely to be turned down on the grounds that they have no effect on a mainline kernel, who's going to fund that work ?

I think there's actually funding for this kind of work.

No more grsecurity test patches

Posted Apr 30, 2017 18:59 UTC (Sun) by MattJD (subscriber, #91390) [Link]

> PaX is a strict superset of SMAP

Is there any documentation on how PaX is better then SMAP for SMAP related duties? It would seem to me once you cut out unwanted data fetches/code execution you've reached the limits of what those features are trying to do. Is there something missing in the hardware? Or something missing in the kernel's implementation?

Or is it that PaX has other exploit migrations that are relevant to SMAP (though definitely relevant to people, to be clear)? I'm genuinely curious to read up on how PaX is better.

No more grsecurity test patches

Posted Apr 27, 2017 14:43 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

So, " they are unwilling to work with the upstream Linux kernel community" isn't quite true - least, it's more complex than that. They /did/ try to upstream stuff, a long time ago. Unfortunately, not with much success:

1. spender can get very, uhm, unproductively defensive in response to any push-back, queries or (esp.) perceived criticism. (As can be observed here, as much as linux-kernel in the past)

2. Linus is pretty famous for being derisory of the security world and security fixes, and IIRC he was pretty personally harsh on spender back when he was still trying to upstream stuff.

These two things have led to the current situation, where spender and PaXTeam are pretty hostile the linux-kernel people, and vice versa.

The Linux Foundation then went and /paid/ (a number of)? people to work on spender/PaXTeam's work. Now spender has said here he'd never take LF's money, but that he has mentioned money a few times suggests this may be still be a sore point. I don't know if the LF tried at all to engage spender/PaXTeam before doing that, or find some way to work together. If not, then it is easy to see how this would have inflamed things further, by the LF leaving them out in the cold .

Anyway, 'tis sad.

No more grsecurity test patches

Posted Apr 28, 2017 15:05 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]

The KSPP doesn't have its own resources, but the CII (Core Infrastructure Initiative) might fund people to work on it. I believe there were discussions between CII and PaXTeam at one point.

No more grsecurity test patches

Posted Apr 26, 2017 20:31 UTC (Wed) by ledow (guest, #11753) [Link]

I would argue that in the same way "social engineering" is a valid attack tactic for the same kind of people who attack our systems, the people who wish to put their code into our systems need pass the same kind of social tests against them as they submit their code.

Now, bear in mind, I'm inherently asocial personally. This is not a case of someone just saying "he needs to be like us, get down the pub and loosen up". But it's not hard to be distant, professional and not take things personally, even if we sometimes slip, and the person behind this project has a history of not only not accepting criticism but actively attacking those who give it. I've said here, to the person in question, that they are obviously skilled but the way they deal with people means that doesn't get utilised properly because of the nonsense and superiority complexes around it.

This does affect the reliability and security of those patches - it makes them a target, it removes the "third-party voice" of others saying "I noticed X in your code, and it didn't look right, is that correct?", and it means that details and time get lost in the argument. Have you ever dealt with someone who, afterwards, you just thought "That wasn't worth the time and trouble it caused, I won't bother to help again unless I absolutely have to"?

And, to be honest, I don't see how being secure and open is compatible with locking the patches away, nor with how locking them away is compatible with the licensing (because, although suspending an account because they dared spread the GPL-code they were given as part of a closed group is obviously an option, and even one that I can imagine the people in question exercising, I don't see how that's conducive to future business either. One accusation, mistake, rogue employee or even a suspicion and your paid access could be stripped from you).

Part of security, in the literal sense of the term, is to feel secure - with the code, the author, and its future. I can't say, personally, that I would feel secure in that respect. Security isn't just about patching the buffer overflow or making it less likely. It extends far beyond that.

No more grsecurity test patches

Posted Apr 27, 2017 11:24 UTC (Thu) by Hunge (guest, #115338) [Link] (8 responses)

"outside code review" :))

Nope.

That "code reviewer" and "contributor" is the same clown who now expertising in legal issues with 140 character tweets on twitter and spreading FUD about grsec...

No more grsecurity test patches

Posted Apr 27, 2017 16:12 UTC (Thu) by isolus (guest, #115212) [Link] (7 responses)

Who is everyone even talking about? What twitter account, what code review?

No more grsecurity test patches

Posted Apr 27, 2017 22:30 UTC (Thu) by karkhaz (subscriber, #99844) [Link]

This thread:

https://twitter.com/marcan42/status/724745886794833920?la...

No more grsecurity test patches

Posted Apr 28, 2017 17:16 UTC (Fri) by Hunge (guest, #115338) [Link] (5 responses)

Read PaX Team comment below:

https://forums.grsecurity.net/viewtopic.php?t=4342

The guy reported a false positive alert in PaX size overflow detection. This PaX feature prevent various integer overflows in function size parameters. However the Linux kernel code is of varying quality (as Andrew Morton said) so there are all kind of programming solutions for certain tasks. Sometimes the developers (wrongly) using signed integers for "length" or "size" fields which cannot be negative. Sometimes they making casting madness with them. Theese programming mistakes lead to security related bugs, sometimes does not. The PaX size overflow plugin cannot make a difference between a security bug or a "creative" programming solution. In the latter case Ephox (the size overflow plugin developer) and the PaX Team tries to circumvent the false positives and rewrites the affected code to work without overflowing the integers. This is not always be easy because GCC optimization makes similar size overflows in generated intermediate codes which are not always controllable by the GCC plugins (what they use). This time they overlooked the problematic code area and fixed the overflow partially.

The really great thing about the PaX features are the proactive prevention and self-protection against their own (and the kernel developers) mistakes too. The PaX detection still catched the partially fixed overflow and (in this case) made kernel panic to stop a potential attack. Some kernel exploits (like sd's k-rad) attack similar overflows in the past so the default behaviour for a detected size overflow is to make kernel stop in a fully controlled manner. For users whoes threat model, risk analysis or IT infrastructure design treats this behaviour unacceptable there are a pax_size_overflow_report_only kernel parameter to disable systematic kernel panic on a detected overflow. This is the decison of system administor or the concerned IT Operations Divison or the IT Security Divison or something like that, depends on the corporate structure and other details.

The sensation-maniac twitter troll found this false positive alert and made like-hunting and retweet-viral messages, saying grsecurity has poor code quality and noone audits it. Spender tried to explain him how this PaX size overflow plugin works but this Marcan guy repeated his nonsense all the time and resumed his campaign. When Spender fed up the useless explanation and deleted his own twitter account the Marcan guy came to the #grsecurity IRC channel for more shit stirring and trolling. When spender banned him he went to TheRegister and said he is an "innocent vulnerability spotter" who are persecuted...

I fully understand that PaX Team and Spender are sick of this hypocrite "community" and turned to another way after 16 years. I wish them good luck and I hope they will be rich in success with their new works too.

No more grsecurity test patches

Posted Apr 28, 2017 17:53 UTC (Fri) by pizza (subscriber, #46) [Link] (4 responses)

> When Spender fed up the useless explanation and deleted his own twitter account the Marcan guy came to the #grsecurity IRC channel for more shit stirring and trolling.
> I fully understand that PaX Team and Spender are sick of this hypocrite "community" [...]

Why are you tarring/blaming the entire "community" for the actions of one person?

No more grsecurity test patches

Posted Apr 29, 2017 18:40 UTC (Sat) by Hunge (guest, #115338) [Link] (3 responses)

This is just an example of many... and as "community" i mean every player from hostile parties to big corps too who benefits from grsecurity and PaX projects and returns nothing.

No more grsecurity test patches

Posted Apr 30, 2017 16:50 UTC (Sun) by flussence (guest, #85566) [Link] (2 responses)

Maybe grsecurity would like to go and develop its own kernel from scratch, then.

No more grsecurity test patches

Posted May 2, 2017 8:55 UTC (Tue) by Hunge (guest, #115338) [Link] (1 responses)

Or just give their security patch who deserve it... oh, wait, this is what they do! :)

No more grsecurity test patches

Posted May 7, 2017 20:25 UTC (Sun) by nix (subscriber, #2304) [Link]

The nice thing about the GPL is that you get to use, modify and redistribute the code freely even if some upstream author doesn't think you "deserve" it. (And given that, as pjones has noted, without assholes your system would not boot, you can be fairly sure that at least one upstream author would hold that opinion of you, no matter who you are.)

No more grsecurity test patches

Posted Apr 28, 2017 3:57 UTC (Fri) by citypw (guest, #82661) [Link] (5 responses)

I think what you mean code review event is this one:
https://www.reddit.com/r/programming/comments/4gn0dr/hect...

It was just a DoS attack but some ppl was misunderstood as PaX/Grsecurity can be exploited. Otherwise, trolling is never make the world more secure, isn't it?

We all know Spender's personalities. But the question is do you really care? Really? The time proved PaX/Grsecurity is the most effective defensive solution to both commercial & FLOSS world. I've been through those old good days of "one null-ptr deref can root them all". The only option I had was KERNEXEC/UDEREF. This is only one tiny study case happened in past decade. PaX team and Spender can make their work closed and make money in the 1st place. They also can apply their work in other OSes rather than Linux. But they didn't. They shared their stuff with FLOSS world for 16 years and for what?

They don't get the credits what they deserves. Those shitty PR seems like Linux foundation is the hero saving the world. From my very narrow( as a security consultant and a FLOSS supporter) perspective, Linux foundation should pay for all of this, including all PaX/Grsecurity users who lost test patch.

The Linux Foundation's role

Posted Apr 28, 2017 13:40 UTC (Fri) by corbet (editor, #1) [Link] (4 responses)

So I'm curious. What, in particular, do you think the Linux Foundation has done wrong in this setting, and what should it be doing differently? This is a serious question; there are ways of communicating serious answers to the right people at the LF. Please bear in mind that the LF does little development of its own, is not running the kernel self-protection project, and cannot mandate the merging of any specific code...

The Linux Foundation's role

Posted Apr 28, 2017 18:51 UTC (Fri) by Lionel_Debroux (subscriber, #30014) [Link] (1 responses)

citypw will provide a reply of his own if he wishes to. I'll attempt to describe something that I think could make an impact, maybe you or someone else will find it interesting.

You're right to point out the limits on what the LF can do. It presumably cannot override, for instance, employee Linus' veto on MEMORY_UDEREF and KERNEXEC, which can protect, with some performance cost, up to a billion or so x86/x86_64 computers without SMAP and SMEP support, better than SMAP and SMEP do (cf. one of the KS 2015 articles, https://lwn.net/Articles/662907/ and my comment there, linking to comments by PaXTeam and spender).
The LF can, however, participate in funding activities focused on to improving the kernel's code base. Some would argue it fits its members' business interests. Funding Emese Revfy's integration of the GCC plugins infrastructure through the CII was a good thing. And there's much more to do for expanding the self-protection work, both groundwork (base infrastructure for any given feature), and perhaps more importantly, actually using, and building on top of, said infrastructure. I mean that, if in the mainline kernel, CONSTIFY and RANDSTRUCT eventually became integrated, but were used only for a dozen whitelisted struct instances in the mainline kernel, they would be close to useless in practice: grsec's CONSTIFY and RANDSTRUCT protect hundreds of struct instances.

Of course, a sizable number of changes for building on top of the base infrastructure, and performing other worthwhile cleanups and improvements, is already available among the ~10K hunks which can be seen in the latest grsecurity patch for 4.9. Let's give several examples of these interesting bits from PaX/grsec:
* using explicit struct members throughout the code, which is a prerequisite for making RANDSTRUCT more useful. There are hundreds of such hunks, I think that 4 randomly chosen, simple and related samples are in drivers/net/wan/z85230.c;
* getting rid of those many wrong casts between incompatible function pointer types, which often does not require adding wrappers, and may make the code more readable to some. Again, hundreds of hunks, which made up the bulk of the PaX & grsecurity patches' size increase when RAP was added. Hunks for lots of WiFi drivers, not limited to drivers/net/wireless/atmel/atmel.c , drivers/net/wireless/cisco/airo.c , drivers/net/wireless/intersil/hostap/hostap_ioctl.c and drivers/net/wireless/realtek/rtlwifi/pci.c , seem to belong to that category;
* building constant structures at compile-time (and making them const) rather than emitting both the room for that structure in a writable section (...) or on the stack, and the code to initialize that structure. That's related to CONSTIFY. See the hunks for drivers/mfd/rn5t618.c , for drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.* , for drivers/net/wireless/ath/wil6210/pcie_bus.c , most of the hunks for drivers/net/ethernet/amd/xgbe/* ... and hundreds of others;
* much less common, but a sample of the untapped tidbits from PaX/grsec: removing spurious "static" keywords on function-local variable declarations when the first thing the function does with the variable is to reinitialize it. See e.g. the drivers/mfd/max8925-i2c.c and drivers/mfd/tps65910.c hunks, both of which were already in a grsecurity patch for 3.14 from May 2014 laying around on my HDD.

Splitting hundreds of these hunks into a sane number of separate patches, submitting them, pinging the maintainers after they fail to pick them up (as largely occurred for Emese Revfy's large submission of constification patches years ago), is a huge amount of work... way too much work for a small team of hobbyists.

I'll stop here, this post is becoming lengthy :)

The Linux Foundation's role

Posted Apr 28, 2017 23:22 UTC (Fri) by mdolan (subscriber, #104340) [Link]

grsecurity is not in any way related to the LF. It is a for-profit organization doing what works for it's business model and the LF has no control over that or say in the matter.

I also don't think many in the community would appreciate the LF mandating code changes outside the normal community process - even if it would make you happy in the short term.

However, the LF can fund a proposal to help improve security. I'm not seeing in your comment that a proposal was rejected, so I'd encourage you to submit a CII proposal if you see a gap that could be worked on. Security is a very important but challenging area and "the LF" won't think of all the great ideas many in this community likely already have.

The Linux Foundation's role

Posted Apr 29, 2017 6:38 UTC (Sat) by citypw (guest, #82661) [Link] (1 responses)

Are you seriously think they will talk to individual or small business? I don't wanna name LF ppl's name I've met here.

https://lwn.net/Articles/703000/

btw, it doesn't matter now. Most of PaX/Grsecurity users lost their free access to test patch already. I'm not good at community politics but the things I've always know is there are a bunch of server/desktop/embedded-devices needed to be protected. We made our point very clear:

https://hardenedlinux.github.io/announcement/2017/04/29/h...

The Linux Foundation's role

Posted May 7, 2017 20:28 UTC (Sun) by nix (subscriber, #2304) [Link]

Wow that's a conspiratorial post you link to. Frankly, the ones to blame for the withdrawal of public grsecurity test patches are... the people who withdrew those patches. The Linux Foundation couldn't withdraw them if it wanted to (which it probably doesn't), so I don't see how they could possibly be blamed -- unless you had pre-emptively decided they were guilty, of course.

No more grsecurity test patches

Posted Apr 26, 2017 23:20 UTC (Wed) by karkhaz (subscriber, #99844) [Link] (1 responses)

Any Alpine Linux users here, who know how Alpine is going to respond to this?

A quick poke around in the forums/mailing lists doesn't reveal anything obvious. Alpine has always distributed an "unofficial port of the grsecurity/PaXTeam" patchset, whatever that means, I wonder if this is going to change?

I'm wondering as a long-time Arch user who has been vaguely fantasising about trying out Alpine for a while now...

No more grsecurity test patches

Posted Apr 27, 2017 8:17 UTC (Thu) by jrigg (guest, #30848) [Link]

There's a discussion on alpine-devel about this:
http://lists.alpinelinux.org/alpine-devel/5626.html

No more grsecurity test patches

Posted Apr 27, 2017 7:24 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link] (4 responses)

On the one hand, I can't say I'm not disappointed that my computers may soon have to revert to highly insecure mainline kernels without the powerful features in PaX/grsecurity, though I'm curious about the community effort mentioned by spender. I can't afford paying a grsecurity subscription alone, and there's no such thing as subscription for individuals without a company, AFAIK. I relied on the test patches for free, despite the occasional donations.
On the other hand, I do understand that working on next-generation features is more fun than having to spend time fixing and counseling the slow and bad mainline integration of a small subset of the less important features of PaX/grsec, and that the work on the next-generation features will yield benefits in time... so I wish them the best of luck on their new endeavour :)

Until a sea change of mind wrt. security is forced through the whole mainline contribution tree, from the top down (similar to, and of the same magnitude as, the change of mind wrt. FLOSS at Microsoft under Satya Nadella's new leadership - and to a lesser extent, the secure development guidelines much earlier at Microsoft), mainline security will remain a lost cause. Of course, it's entirely possible to work around the well-known heavyweight roadblocks, like PaX/grsec has been doing for over a decade and a half... but is any corporation _willing to_ create and maintain a _sustainable_ security-oriented fork of Linux, based on PaX/grsec ?
It's not a matter of ability or money: the likes of Google have hundreds of full-time security engineers, and _could_ easily add dozens of persons working full-time on maintaining and evolving a hardened fork of Linux. It would probably even be an excellent PR move.

No more grsecurity test patches

Posted Apr 27, 2017 12:10 UTC (Thu) by arjan (subscriber, #36785) [Link] (3 responses)

why a fork? why not mainline all the good pieces?
(as the Kees and his project are trying to do)

No more grsecurity test patches

Posted Apr 27, 2017 14:54 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link] (2 responses)

Because sadly, some good pieces - including the most powerful defenses against exploits provided by PaX+grsec - cannot be mainlined, for bogus reasons :(
I detailed that in my other comment above, https://lwn.net/Articles/721122/ .

No more grsecurity test patches

Posted Apr 27, 2017 15:04 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

I feel compelled to note out that nowhere in your wall of text did you actually say what those reasons were. So, um, [ citation needed ]

(As an aside, I've personally seen pushback on some of the PaX/grsec stuff because it would have broken bits of the userspace ABI -- about the only true no-no that Linux has. So there are quite often good reasons for saying "no", but I cannot comment if any of that applies..)

No more grsecurity test patches

Posted Apr 27, 2017 15:39 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link]

> I feel compelled to note out that nowhere in your wall of text did you actually say what those reasons were.
Er... I did in the sentences following the occurrence of "entirely bogus reasons" in my post above ;)

> So, um, [ citation needed ]
Easy :)
Linus' statement that the hardware does it is covered near the beginning of https://lwn.net/Articles/662907/ , written by the LWN editor Jon Corbet, summarizing a discussion of the Kernel Summit.
The fact that even run-of-the-mill x86_64 hardware does it worse than MEMORY_UDEREF and KERNEXEC is covered by spender and PaXTeam in e.g. https://lwn.net/Articles/517749/ , https://lwn.net/Articles/617945/ . That's what I used to build the older LWN comment of mine ( https://lwn.net/Articles/663329/ ) I referred to above in this thread.

> I've personally seen pushback on some of the PaX/grsec stuff because it would have broken bits of the userspace ABI
A subset of the user-space breakage (at least behavioural breakage, not necessarily ABI breakage) is configurable at both build and run time, but I wouldn't feel qualified either to comment whether said subset is strict :)

No more grsecurity test patches

Posted Apr 27, 2017 13:09 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (2 responses)

This could be an indication that GrSecurity feels threatened by Kernel Self Protection Project.

Perhaps the business model that involves spreading FUD about the project your product is largely based on instead of giving back to it no longer pays off. That is a good thing.

No more grsecurity test patches

Posted Apr 27, 2017 15:01 UTC (Thu) by Lionel_Debroux (subscriber, #30014) [Link]

I think it's extremely unlikely that they feel threatened in any way by the output of the KSPP, given how little output KSPP has produced... despite Kees' efforts, and the help PaXTeam, spender and ephox gave :)
Also, FYI, rather than FUD, they're spreading facts. It's a fact that PaX+grsecurity provide a wide variety of efficient defenses against whole classes of attacks, just look at https://grsecurity.net/compare.php for yourself. As a result, not only a PaX/grsec-patched kernel is vulnerable to fewer issues than a mainline kernel in the first place (even without enabling special config options - a number of hunks in the patch rightfully live outside any config option), but also, these issues are harder to exploit.
Other facts: the size of the PaX and grsec patches has more than doubled in the past three years, more than quadrupled in the past six years, and has kept *raising* since the KSPP was started.

In the past few years, examining in LWN comment threads how the mainline kernel repeatedly failed to prevent published PoCs mentioned in LWN news articles had become a game played multiple times per year, mostly by spender. It wasn't unusual that said PoC would have been killed by at least *4* protections from PaX+grsec.
Let's detail the list once more: the PoC often made the kernel dereference stuff in user-space (forbidden by MEMORY_UDEREF, even without special hardware support available only in e.g. the two most recent generations of x86_64 computers), then execute the payload in user-space (forbidden by KERNEXEC; in mainline, a weaker protection requires special hardware support as well)... all of that often occurred after rewriting an internal data structure which shouldn't have been writable in the first place - and indeed wasn't in PaX/grsec with CONSTIFY - and which had a predictable layout, so the exploit was unlikely to work with RANDSTRUCT (but using a distro kernel nullifies the benefit of RANDSTRUCT). The PoCs I remember about didn't even bother throwing in a sprinkling of ROP... but had they done so, in the past year, they'd have been killed by RAP.

No more grsecurity test patches

Posted Apr 29, 2017 12:33 UTC (Sat) by adobriyan (subscriber, #30858) [Link]

KSPP is copycat of grsec/pax in the same sense as some open source clones of proprietary software exist solely for the purpose of being open source.

What are private users going to do?

Posted Apr 27, 2017 16:23 UTC (Thu) by Seegras (guest, #20463) [Link]

Those that can't afford any company-style subscriptions? People like activists depending on secure systems because some totalitarian state is trying to break into their machines?

And the FAQ https://grsecurity.net/passing_the_baton_faq.php does sound like a lot of marketing hogwash too: "we will be tackling the vector holistically, building on top of the strong security guarantees provided by RAP, our best-in-breed defense against code reuse attacks."

Really, it does rather sound like some three-letter agency made them an offer they can't refuse.

No more grsecurity test patches

Posted Apr 28, 2017 15:43 UTC (Fri) by dps (guest, #5725) [Link]

IANAL but it is almost certainly critical what Open Source Security Inc actually dsibtribute. If it is just patches and those patches are not derivative works of the kernel then they can probably use any license whatsoever. I won't venture into the mine field about what is and what is not a derivative work.

As soon as the grsecurity patches get applied to the kernel source code then the patched kernel source code, compilations if it, etc are derived works of the GPLed source code, so need to be either distributed according to the GPL or not distributed at all. It might be legally possible to ask people not to distribute the patched source code, or compilations thereof, but that would be more difficult. The GPL FAQ says that is permissible to develop a modified version under a NDA and agree not to distribute your changes.