41–50 of 82 posts
Earlier quoted context omitted.
They work together.
We have no real evidence of that other than it's what Brad Spengler says.
Earlier quoted context omitted.
In other words: nobody ever tried to get it into mainline. Anyone reading this right now could go and get it submitted into mainline in the chunks that Linus would accept. It would take about 6 months, though, assuming you knew what you were doing.
Incorrect, Kees Cook, who more or less founded the KSP project (kernel self protection) has been working on this for several years to enhance the security of ChromeOS while working for google. He started some of it when he was working for Canonical and has been doing this non-stop. The problem is that getting things into small individually testable components is literally anathema to the Pax/grsecurity model. They ha…
no, you're wrong. how do you think we developed our code? did all the 8+ MB worth of it pop out of our head all at once? or more realistically, did we develop the features piece by piece, not unlike how upstream linux is developed?
> They have very specific "chunks" of functionality which are quite invasive, by design.
define invasive. linux itself has 'quite invasive' features too yet that didn't prevent them from being developed and upstreamed, so not sure what you were trying to imply here.
> This goes against the model the Linux kernel is developed, so the two development > communities are simply mutually exclusive.
this narrative only exists in your head, not in reality. our work is as much upstreamable as any other kernel code that went in over the years (how else do you think some of it could get in already?), it's just that it can't be done in one's free time.
Earlier quoted context omitted.
In other words: nobody ever tried to get it into mainline. Anyone reading this right now could go and get it submitted into mainline in the chunks that Linus would accept. It would take about 6 months, though, assuming you knew what you were doing.
Incorrect, Kees Cook, who more or less founded the KSP project (kernel self protection) has been working on this for several years to enhance the security of ChromeOS while working for google. He started some of it when he was working for Canonical and has been doing this non-stop. The problem is that getting things into small individually testable components is literally anathema to the Pax/grsecurity model. They ha…
Other people have gotten large changes into the kernel before, but they require interfacing with the kernel devs and agreeing to certain changes first. Nobody's going to accept a patch just because Google wants it for one of its products. And Google isn't going to change its product patches just so they can fit in mainline.
How does this work at a licensing level? GRSecurity are patches to the Linux kernel right? Can you distribute patches for a GPL licensed software without the patches themselves being GPL?
grsec has had a commercial program for a while. The way these things tend to work is "It's GPL, but if you redistribute it publicly we terminate your subscription with no refund." (I think RHEL binaries work the same way, for instance.) The reason for companies to pay is to get reliable updates for new versions, so that they can avoid hiring a bunch of people in-house to build / forward-port things. So usually this i…
You say "burn a subscription", does that mean you assume the patchsets are earmarked? And wouln't simply... two subscriptions and a diff fix that?
Earlier quoted context omitted.
I think they're just tired of doing work and the kernel community going shrug (or worse, dismissing it). Of course, the kernel developers are also doing work for free, but at least their work is actually being accepted into the kernel. Maybe they're just thinking "our customers value our work, so let's focus on providing value to them instead of to people who don't value our work". Whether or not that's true, I don't…
That is pretty much what Spengler says in the Stack Overflow question where this was asked directly.
Earlier quoted context omitted.
That's not the same thing at all. The 'P' taint flag exists because upstream kernel maintainers aren't interested in dealing with bug reports where the bug may have been caused by proprietary code loaded by end users, which often can't be examined or copied even for the purpose of discussing the bug. Total waste of time, so the flag makes those cases obvious to anyone reading the bug report. The user can be told upfr…
> It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all. Is this true? I would think that as long as your "new" code is sufficiently distinct from the stuff you're replacing, you'd be fine distributing a non-GPL patch (at le…
On the other hand, seeing how everyone turns their back on you when you do try to prosecute GPL violations (e.g. SFC and the VMWare GPL lawsuit), I can see why the Linux maintainers don't try to enforce their copyleft. It certainly doesn't help that the Linux foundation is almost entirely run by companies that do not want the GPL to have teeth.
Earlier quoted context omitted.
That's not the same thing at all. The 'P' taint flag exists because upstream kernel maintainers aren't interested in dealing with bug reports where the bug may have been caused by proprietary code loaded by end users, which often can't be examined or copied even for the purpose of discussing the bug. Total waste of time, so the flag makes those cases obvious to anyone reading the bug report. The user can be told upfr…
> It could never be licensed in a way that prevented the patch set or the resulting patched kernel source/binaries from being covered and distributed under the GPLv2. If that were the case, the kernel would effectively not be covered by the GPL at all. Is this true? I would think that as long as your "new" code is sufficiently distinct from the stuff you're replacing, you'd be fine distributing a non-GPL patch (at le…
I love how grsecurity is always quick to point out how generous they have been by providing the patches for free. > We have been providing grsecurity freely for 16 years. Meanwhile the kernel upon which their work is built has been provided for free for much longer, and continues to be.
you conveniently forgot to mention the fundamental difference: the upstream kernel isn't developed for free whereas our code has always been. changes the equation quite a bit, doesn't it?
And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam?
Earlier quoted context omitted.
Torvalds claims [0] that he did not do enough arguing with upstream: > The apparent inability (and perhaps more importantly - total unwilling[n]ess) from the PaX team to be able to see what makes sense in a long-term general kernel and what does not, and split things up and try to push the sensible things up (and know which things are too ugly or too specialized to make sense), caused many PaX features to never be me…
PaX is developed independently from and usually shipped with grsec patches. AFAICT Spengler's not directly involved, and Torvald's comments don't reflect on them.