GrSecurity Kernel Patches Will No Longer Be Free To The Public

[oiaohm]

Can you please explain what this is supposed to mean?

waah waah grsecurity people don't want to make patches for other archs waah waah they are baaad waah waah.

They write stuff, they can decide to not care about archs they don't use/like/whatever. This isn't a proof of any wrongdoing, it's not breaking any rule.

It does in fact break a rule the Linux kernel includes a generic section for a reason. So large percentage of grsecurity is patched into the wrong section of the kernel tree since they were in x86 when they should have been in generic section. They have recently started to have to re-factor it. Part of the reason I see for them going closed to general public is avoiding have egg on face as they re-factor the patches showing they had been doing them wrong all the way along.

When you are doing a modification to core of Linux kernel you are meant to seriously consider if it a generic alteration or a architecture particular alteration. Yes for years grsecurity team has taken the lazy way out and skipped doing this. It is one of the big differences with

You're reading that post wrong. The way they "fixed" the issue is by adding their system (PaX) that makes kernel infoleaks impossible to exploit even if there are known bugs as it randomizes kernel structures so any attacker can't know where to look to exploit them.

No you did not read the bug right. Info leak bug is not prevent by KASLR of any form. It was only fixed by those 2 lines of alteration that was applied to mainline 4 years later than grsecurity and grsecurity got upset because they did not get credit.

So that was a fault that should have been sent mainline.

This particular one has been fixed already in grsecurity the same way since August of 2012
The developer is very clear that the grsecurity patch set contained the exact same patch since 2012. He was upset that someone implemented the same thing and took credit. Its call parallel development. The one that took credit mainline never looked at grsecurity. So if he wants credit all the time for those little things better submit it mainline or live with miss out of credit.

The way to beat kernel KASLR is exploit information leaks. The reality is not that mainline Linux kernel KASLR is defective yes as of 4.12 its going to be default on x86 kernels under Linux with other to follow.

http://www.cc.gatech.edu/~yjang37/assets/papers/2016/jang:drk-ccs.pdf

This is the paper grsecurity author references but does not provide link. PAX KASLR is just a weak to the attack as what mainline KASLR is. Also he goes on to claim that KASLR is worthless under arm64 even that it has been documented to block particular classes of bugs on Arm64. So this is more hey we have not managed to-do that so we will call it pointless instead of admitting they were beaten to the punch.

KASLR weakness is if kernel memory information leaks the randomisation can be decoded and attack made functional.

They don't want credit, they want money. Which isn't wrong per-se.

The grsecurity developers want both credit and money. The reality here is if you don't submit mainline expect at times to lose your credit it parallel development.

I really don't care of most of the waah waah you post, I need proof that what is in the kernel is decent enough.

The grsecurity patches were not decent enough either. Kernel driver developers were not testing against grsecurity or design in information safe ways so there have been lots of security holes. You only need to follow when the Linux kernel blocked read/writing to userspace without using protection functions with how many drivers broke. Over half of those turned out to be exploitable information leaks that grsecuirty patches did not fix.

The reality is grsecuirty has been attempting to put up a tent on quicksand. Lot of mainline work is required to make the kernel core stable to build on top of. The Linux kernel has been security quicksand and grsecurity guys have been fooling themselves and others that they could in fact fix it without doing the mainline work.

[oiaohm]

It would be "compatible" in the legal sense if it forbids distributing of the patched software since the GPL rules only come into play when you distribute the software, unless the patch is a derivative work and thus also GPL-licensed by default. If you have a citation showing that a patch is a derivative work, please provide it. As I said, I wasn't able to find any reliable source one way or the other.

You need to look to German and USA court ruling in this. To not be a derivative the code has be able to function without the GPL work. Vmware case is tricky as vmware esxi can operate without the Linux kernel. Grsecurity without question does not function without the Linux kernel so fails the basic legal test so is a derivative work without question. Companies making routers have argued these points in USA and German courts and been told their code is GPL no matter how they slice the source code.

These ruling do provide problems for those doing zfs drivers under Linux. Even a lot of closed source drivers are questionable.

[TheBlackCat]

You need to look to German and USA court ruling in this. To not be a derivative the code has be able to function without the GPL work. Vmware case is tricky as vmware esxi can operate without the Linux kernel. Grsecurity without question does not function without the Linux kernel so fails the basic legal test so is a derivative work without question. Companies making routers have argued these points in USA and German courts and been told their code is GPL no matter how they slice the source code.

These ruling do provide problems for those doing zfs drivers under Linux. Even a lot of closed source drivers are questionable.

Again, which rulings, specifically, are you talking about? Do you have links to the cases? I have asked several times for citations.

[oiaohm]

Again, which rulings, specifically, are you talking about? Do you have links to the cases? I have asked several times for citations.

Its first covered in the 2004 German ruling for GPL. Its been brought up in fairly much every GPL case when it come to compliance.

https://yro.slashdot.org/story/04/07/23/1558219/german-court-says-gpl-is-valid

How to interpret section 2,3 and 4 of GPL v2 is in that case.

https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

Those interpretations are reaffirmed by USA and German rulings since. So it does not matter what ruling you pulled up just any one of the rulings in the USA and German courts even the vmware one recently state the test and it not disputed.

Yes that is the derivative work stuff and what is the test. Nvidia binary/source wrapper driver passes the 2004 test as the blob can operate without the Linux kernel and they can demo it operating other other OS's like Freebsd and windows.

Vmware usage in esxi could also be on the legal side of the test with a little bit of fair usage thrown in. Grsecurity PAX not so lucky. it fails the test without question.

So sections of what is derivative work is at least partly defined and Grsecurity PAX is for sure on the wrong side.

Please note section of Nvidia binary driver the source wrapper is gplv2 for where it makes too much contact with the Linux kernel to pass the independent work test.

Lot of people get the foolish idea they can make a Linux kernel patch and ship it under some license other than GPLv2 of their choosing. Yes the license of a patch can be not GPLv2 but it has to be GPLv2 compatible. So you can make your Linux kernel patch MIT license for example. Since a person who gets your MIT license code can ship it as GPLv2 you have not broken the rules.

zfs for Linux is in a legal grey area that has not been tested in court. Might be fine due to being able to demo that zfs comes from some other OS it also might be complete breach. Would take a court case to sort out.

Basically Grsecurity PAX license options are limited. To be unlimited in license they have to demo multi platform support.

The Nvidia example once linked into a binary is no longer shippable and it can use the loop hole of ship to client then no more.

[TheBlackCat]

Its first covered in the 2004 German ruling for GPL. Its been brought up in fairly much every GPL case when it come to compliance.

https://yro.slashdot.org/story/04/07/23/1558219/german-court-says-gpl-is-valid

How to interpret section 2,3 and 4 of GPL v2 is in that case.
https://www.gnu.org/licenses/old-lic...pl-2.0.en.html

That case is about some distributing software, not just the patches. I don't see anything in there about patches at all. Can you please point to exactly what you are talking about?

Vmware usage in esxi could also be on the legal side of the test with a little bit of fair usage thrown in.

Again, they are distributing software, not patches, and that software includes a chunk of kernel code from the summary I can find.

[Nth_man]

If it may be useful:

Dutch Court Rules That Freely Given Fan-Subtitles Are Copyright Infringement
https://www.techdirt.com/articles/20...ingement.shtml

Fan-made subtitles for TV shows and movies are illegal, court rules
https://arstechnica.co.uk/tech-polic...s-are-illegal/

A commenter wrote that

To be as terse as possible, the translated "sub" is technically a derived work distributed without permission (that's really the infringement part) from the copyright holder.

although I am not a lawyer.

It reminded me of what ssokolow wrote:

Patches are derived works because they aren't sufficiently useful without being applied to the base work.

[oiaohm]

That case is about some distributing software, not just the patches. I don't see anything in there about patches at all. Can you please point to exactly what you are talking about?


Again, they are distributing software, not patches, and that software includes a chunk of kernel code from the summary I can find.

Its covered in the full transcript.

2004 case is both full software and patches. As patches used in the 2004 case come from other parties so ruling was required if GPL in fact applied to those to allow the one who has used the patches to release the source code instead of recall the product.

The Sub title case is based off the 2004 GPL ruling. So this derived work issue effects a lot of things.

Summary on those cases is incomplete. Its the compliance part of the rulings that cover the legality of patches and that is in the full transcript not the summary..

[TheBlackCat]

Its covered in the full transcript.

*sigh* Is it really so hard to link to a PDF and say "look at page X-Z" in this document? Your link was to a German version of the ruling, with a vague promise that an English version will come later. The only English version I can find is for original case, not the appeal.

[oiaohm]

*sigh* Is it really so hard to link to a PDF and say "look at page X-Z" in this document? Your link was to a German version of the ruling, with a vague promise that an English version will come later. The only English version I can find is for original case, not the appeal.

The full transcript to the 2004 case is in German only. Really full court transcripts have to be paid for. None of this is link to a PDF on the internet and say read this. The only stuff you have in English on the Internet is abstracts and summary that don't include all the important information.

https://arstechnica.co.uk/tech-policy/2017/04/fan-made-subtitles-for-tv-shows-and-movies-are-illegal/

The subtitle case in 2017 is based off the same ruling and again the complete transcript is a pay for item and not in english. So you really need to go proper copyright lawyer who should paid for the documents and the translations.

TheBlackCat the reality is not everything is on the Internet some you have to order in hard-copy and at time pay people to have access to that information. You are making the presume you don't have to-do that. I have provide you with the information you need to take to legal to answer you question.

[Guest]

TheBlackCat They might not have to reveal the patches themselves, but if they are distributing patched kernel binaries, then the GPL definitely applies, and they do have to provide the patched source code, although they don't have to point out what changed.