LWN: Comments on "No more grsecurity test patches"

The Linux Foundation's role

nix — Sun, 07 May 2017 20:28:09 +0000

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

nix — Sun, 07 May 2017 20:25:03 +0000

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

luto — Tue, 02 May 2017 16:20:31 +0000

> 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

Hunge — Tue, 02 May 2017 08:55:21 +0000

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

No more grsecurity test patches

MattJD — Sun, 30 Apr 2017 18:59:11 +0000

> 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

flussence — Sun, 30 Apr 2017 16:50:11 +0000

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

Do-not-distribute terms

Wol — Sun, 30 Apr 2017 10:31:41 +0000

> 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

No more grsecurity test patches

Hunge — Sat, 29 Apr 2017 18:40:57 +0000

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.

Do-not-distribute terms

mathstuf — Sat, 29 Apr 2017 17:01:10 +0000

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.

No more grsecurity test patches

adobriyan — Sat, 29 Apr 2017 12:33:27 +0000

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.

Do-not-distribute terms

PaXTeam — Sat, 29 Apr 2017 08:35:45 +0000

> 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.

The Linux Foundation's role

citypw — Sat, 29 Apr 2017 06:38:20 +0000

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...

Do-not-distribute terms

dsommers — Sat, 29 Apr 2017 00:32:54 +0000

> 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.

The Linux Foundation's role

mdolan — Fri, 28 Apr 2017 23:22:01 +0000

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.

Do-not-distribute terms

PaXTeam — Fri, 28 Apr 2017 22:50:33 +0000

> 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

dsommers — Fri, 28 Apr 2017 21:18:02 +0000

> 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.

No more grsecurity test patches

Lionel_Debroux — Fri, 28 Apr 2017 20:12:21 +0000

> 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 ?

The Linux Foundation's role

Lionel_Debroux — Fri, 28 Apr 2017 18:51:39 +0000

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 :)

Do-not-distribute terms

PaXTeam — Fri, 28 Apr 2017 18:42:17 +0000

> 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?

No more grsecurity test patches

pizza — Fri, 28 Apr 2017 17:53:18 +0000

> 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

Hunge — Fri, 28 Apr 2017 17:16:36 +0000

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

luto — Fri, 28 Apr 2017 16:31:54 +0000

> 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

dps — Fri, 28 Apr 2017 15:43:40 +0000

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.

Do-not-distribute terms

dsommers — Fri, 28 Apr 2017 15:10:53 +0000

> > 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.»

No more grsecurity test patches

BenHutchings — Fri, 28 Apr 2017 15:05:26 +0000

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.

Do-not-distribute terms

PaXTeam — Fri, 28 Apr 2017 14:13:29 +0000

> 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? ;)

The Linux Foundation's role

corbet — Fri, 28 Apr 2017 13:40:28 +0000

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...

Do-not-distribute terms

dsommers — Fri, 28 Apr 2017 12:34:14 +0000

«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

epa — Fri, 28 Apr 2017 11:16:39 +0000

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...

No more grsecurity test patches

citypw — Fri, 28 Apr 2017 03:57:56 +0000

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.

No more grsecurity test patches

karkhaz — Thu, 27 Apr 2017 22:30:28 +0000

This thread:

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

Do-not-distribute terms

mikemol — Thu, 27 Apr 2017 18:51:37 +0000

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

What are private users going to do?

Seegras — Thu, 27 Apr 2017 16:23:48 +0000

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

isolus — Thu, 27 Apr 2017 16:12:35 +0000

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

No more grsecurity test patches

Lionel_Debroux — Thu, 27 Apr 2017 15:39:42 +0000

> 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

pizza — Thu, 27 Apr 2017 15:04:41 +0000

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

Lionel_Debroux — Thu, 27 Apr 2017 15:01:08 +0000

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

Lionel_Debroux — Thu, 27 Apr 2017 14:54:59 +0000

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/ .

Do-not-distribute terms

farnz — Thu, 27 Apr 2017 14:51:17 +0000

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.

No more grsecurity test patches

paulj — Thu, 27 Apr 2017 14:43:45 +0000

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.