GrSecurity Kernel Patches Will No Longer Be Free To The Public

[Wilfred]

Yes upstream responded with break those patches up and resubmit.
https://kernsec.org/wiki/index.php/K...ection_Project
Yes the kernel self protection project is being able to break up GrSecurity features and submit them interdependently. Yes they are not as well optimised as GrSecurity ones. Optimisation can come latter.

GrSecurity could be a jackass and not submit mainline while they did not have competition attempting to do the same things. You think about it you only have enough funds to either support GrSecurity or Kernel Self Protection Project. The Kernel Self Protection Project the fact it going up stream and peer reviewed its going to draw some peoples attention.

The price of not being at least partly mainline it left the door open to competition.

As spender has noted, there are lots of aslr breaks against the vanilla linux kernel to which grsecurity is not vulnerable.
I am inclined to believe that what is now upstreamed is not enough, and spender is right when he claims that the people upstreaming his patches do not understand them and how they interrelate.

[TheBlackCat]

TheBlackCat

They're kernel patches. They are derivative work of the Linux kernel.

Citation needed. A patch doesn't actually have to have any kernel code in it, and even if it does it may fall under an interoperability exception.

[chithanh]

The sales contract agreement might include non-disclosure clauses; leaking the source code to other parties would violate those, so they'd lose access to future versions (and/or other penalties).

Nope. It is not possible to apply additional restrictions on GPL code, whether it is through a sales contract or not. The only exception to this is in GPL 3, when you hire a contractor to do work on GPL software, this does not count as redistribution.

If you try to put additional restrictions on GPL code, this is a violation of the license and you automatically lose all rights to the code.

with GPLv2 (and the Linux kernel is v2 only, not v2+) once you distribute a derived work, *everyone* is entiteled to receive the souce from you.

That is wrong. You have to include along the binary code a written offer that is valid to anyone to distribute source code to them at cost.
But there is no obligation of the recipient of your code to actually hand that offer to someone else.

[W.Irrkopf]

GPL requires you to provide sources to individuals that receive your binary program, not to the world at large.

There are various projects like this that use GPLed code from kernel as if it was basically closed source since they only share with customers, that are obviously unlikely to share with third parties.

Actually no (not in this case): You'd be correct as far as GPLv3 is concerned - but with GPLv2 (and the Linux kernel is v2 only, not v2+) once you distribute a derived work, *everyone* is entiteled to receive the souce from you.
The situation gets less clear in case they provide only patches with no context to their customers.

[stevenc]

Whoever is provided with a grsecurity kernel, has a right to the source code (the whole thing with patches already applied, or a patchset against mainline). If grsecurity only provides kernels to paying customers, only they have a right to the source code. The sales contract agreement might include non-disclosure clauses; leaking the source code to other parties would violate those, so they'd lose access to future versions (and/or other penalties).

If grsecurity customers wanted to put it into consumer products, I'd expect all end-users would then have a right to the source code. So that use case is impractical under these new terms. I suppose grsecurity is rather being marketed for internal use within enterprise and such.

If someone sells VPSes or SaaS/PaaS running on the grsecurity kernel, they can leverage this as a commercial advantage ("grsecurity-enabled hosting"), assuming they can side-step the legal obligations of the GPLv2 (which I'm sure is easy somehow). It seems the FSF had foresight of this kind of situation when drafting some of its newer licenses, that GPLv2 didn't anticipate.

If you find the situation immoral, you should not buy grsecurity or services that claim to be based upon it; support alternative hardening projects that do submit patches back or develop their patchset openly. Or if you don't care either way, BSD is nice too.

[chithanh]

Depends, if grsecurity is not specific to the Linux kernel it might not count as derivative. Having BSD licensed some glue code between kernel and grsecurity might do the trick too.

With other non-GPL stuff like NVidia's proprietary kernel module or ZFS at least some people say it is ok.

[unixfan2001]

TheBlackCat

They're kernel patches. They are derivative work of the Linux kernel.

[TheBlackCat]

Also, AFAIK they can't prevent their customers from releasing the patches (since the patches themselves will be under GPL).

IANAL, but I am pretty sure the patches are not automatically under the GPL. The GPL only applies to the source of software someone distributes. The patches themselves are not software, so they are the work of the company and can be under whatever license they want. I think the only situation where the patches would be under the GPL is if they are considered derivative works, but depending on the patch format there may be none of the original kernel code in them, and even if there was some there are some allowances to use portions of copyrighted works for the sake of interoperability (although those seem kind of fuzzy)

And that would mean that even if the company provided patched binaries, they wouldn't need to provide the actual stand-alone patches, although customers could reverse-engineer them by diffing the original sources with the patched ones (but they wouldn't be able to include the company patch descriptions or patch names).

Again, IANAL, but that is the impression I have gotten.

[oiaohm]

Heh it depends on who you believe.

The big issue here is that there is no unbiased analysis to help see what is actually happening, for example is KSPP doing a good enough job?

grsecurity people of course shit on KSPP at any occasion and link to articles that find vulnerabilities in it that aren't there in their stuff, but they have some obvious bias so heh.

KSPP people don't provide much info, and even if they did it they would still have the bias.

So yeah, it's still too much smoke and mirrors to tell anything for sure.

Problem is you only need to ask yourself a few basic questions.
https://www.raspberrypi.org/forums/v...?f=29&t=160806

Grsecurity have been heavily x86 focused and are still very x86 focused.
https://kernsec.org/wiki/index.php/Feature_List

Notice mips, arm, arm64, powerpc . x86. KSPP is multi cpu coverage this is from working upstream to get stuff into mainline so putting the alterations in front of those dealing with other systems.

https://forums.grsecurity.net/viewtopic.php?f=7&t=4476
If you want to see jackass read this carefully.
Update: shortly after this post, yet another kernel infoleak was posted. This particular one has been fixed already in grsecurity the same way since August of 2012.
So for 4 years grsecurity knows about a security fault and never sends to mainline.
https://git.kernel.org/pub/scm/linux...e25e63f1d945d0
Its a 2 line change. The grsecurity guys cannot point to where in 2012 they put a patch up to the Linux kernel and it was rejected. Because they never did.

So yes grsecruity can point to cases where they had the fix. But most of those fixes prove the are just a huge pack of jackasses who don't care that everyone else using other CPU that their patch set don't cover are effected by those faults.

Faults in mainline kernel not in grsecurity stuff clearly shows issues. Lot of issues of grsecruity leaving people security exposed and them doing nothing to correct it. Every time they get smart ass pointing out flaws you see a lot of fixes appear in the Linux kernel so meaning they cannot sell that as unique features any more.

Yes grsecruity are upset that other people are merging features they developed but they also never attempt to merge those features. So stiff you want credit you should have submitted your features mainline then someone else could not steal your thunder.

[labyrinth153]

I sense a fork incoming!