Passing the Baton
grsecurity.netI suspect this will just shift focus to the Kernel Self Protection Project[1].
It may end up being the best thing that could have happened for kernel security in the end.
[1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
Could KSPP evolve to add missing features that are currently present in grsecurity?
If you're willing to wait a long time, then yes, KSPP, in years, might bring Linux kind-of on par with grsecurity today. If you mean in the short term, well...
What will likely happen is people will base new features on the last public 4.9.x patches, the same way prior KSPP patches have been, such as PAX_REFCOUNT or the read-only static variables, latent entropy, etc. (Frankly most of these are uninteresting compared to the powerful things like RAP, UDEREF, size overflow, etc, and the patches were in some cases neutered in other ways -- but whatever.)
However, grsecurity is more than that; if you watched the RSS feed, substantial amounts of effort went into also monitoring upstream kernels and carefully picking out security relevant commits and closing holes. The -stable grsecurity trees often had (literally) hundreds of included bugfixes that plugged things like minor infoleaks, 'benign' integer overflows, etc, when compared to the stable mainline kernels.
(In fact, there were few better resources for getting a peek at security-sensitive code "in the wild" being analyzed and fixed than looking at the grsecurity RSS feed, IMO. Huge amounts of it was very enlightening to understand what kind of security sensitive issues you can find..)
When a substantial amount of your infrastructure is about anti-memory corruption mitigations, taking care of stuff like infoleaks becomes more important. It is both the combination of all of grsecurity's features -- making most attacks substantially more difficult, or simply outright impossible in a lot of cases -- plus this kind of detailed attention -- not just stopping whole techniques, but also mitigating future possible attacks -- that put it very far ahead of the competition. It is not just a patch set, it is also very much a mind set, and a development model, behind the system.
In short, I don't agree this is the best thing that could happen for Linux Security or the KSPP. It's one of the worst, in fact. I think it means the KSPP will fall even further behind grsecurity as it will now develop all of its new protections privately (such as the whispered KERNSEAL), and they will be left to their own devices to develop new protections. (The current grsecurity authors have over a decade of experience in advanced anti-corruption techniques and kernel hardening, you're already starting the race late.) And even if they do rip the code out of the old kernels, and they do manage to keep it in tact without neutering or removing parts, it's not clear to me the kernels will still have the level of attention or mindset previously seen by the grsecurity team, which means it will overall still be worse off.
I knew this was coming after the -stable trees were pulled. It sucks.
> substantial amounts of effort went into also monitoring upstream kernels and carefully picking out security relevant commits and closing holes
This would better be a project done by these same people, in the upstream, to ensure that the -stable branches of regular kernel packages receive security updates, no?
Brad has already answered this before.[1] In short: they have no interest in cooperating with an upstream that feel -- in many ways -- does not appreciate their work[2], and their view of their work is that it is a complete system and greater than the sum of individual parts, which upstreaming can't solve on its own.
Also, just picking out hundreds of bug fixes isn't really improving kernel security, in reality. It feels good, but it solves very little. It's playing cat-and-mouse, whack-a-mole. You churn 1.5 million lines of code every 3 months, every major release of Linux, add tons of new code, and play the game again. This approach is simply not sustainable in the long run. You also have to have actual mitigation and defense techniques too -- and not just one of them. You need a lot of them, working together.
In short, it's not just about a set of patches, or just fixing some infoleaks.. The entire development process needs to take part in this.
[1] https://unix.stackexchange.com/questions/59020/why-are-the-g...
[2] While I cannot find a link on me, I actually 'fondly' remember a recent memory somewhere from LKML, where someone (an ARM maintainer, I believe) actively lashed out at Kees Cook for "bothering" to do this work and attempting to upstream some of their work such as PAX_REFCOUNT. The reasoning? Because it's "bullshit" to worry about losers who do not upstream, and making their lives "easier" is a load of crap they shouldn't bother with, and it only benefits people "who do not contribute back". At one point they even started ranting about how people like Samsung similarly just 'take' and do not give back. It took several emails to explain, patiently, that in this scenario, it is not about making anyone's life easier, nor benefitting shitty people like Samsung -- it is about protecting users. And it's about having mitigations that will stop exploits today that don't get discovered until 5 years from now when millions of people are vulnerable with exposed devices. This isn't a simple disagreement about how a patch should be implemented -- it is a complete misunderstanding of defense in depth, and true mitigation.
But the backporting-security-patches thing is already done by every distro—just, not as well as grsec+pax do it. Said distro maintainers just need help to get their -stable kernels up to grsec/pax's standard—at which point the grsec/pax patchsets could be based directly on top of each distro's -stable kernel package, rather than having to do all the work of backporting again themselves.
Which would, of course, free up resources on the grsec/pax side to go toward protecting users; and, moreover, would also partially protect those users who just rely on their distro's -stable kernel, more than they're being protected today.
Perfect is the enemy of good; ideal security is the enemy of less vulnerable.
Also read the corresponding FAQ: https://grsecurity.net/passing_the_baton_faq.php
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 incentive works.
Now that grsec is completely unavailable without a paid subscription, either source or binary, it'd be interesting to see if the incentive holds up, or whether someone wants to burn a subscription to get a version out to the public. I imagine that they're cautious about who they allow to sign up as a customer.
RHEL binaries are, well, binaries. A patchset like grsec is source. I don't think RHEL restricts source redistribution, which they seem to release publicly anyway.
Is the commercial version (still) GPL'd, though?
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?
The kernel remains GPLv2, so the standard licensing issues apply: you can make changes, but if you distribute the changes, you have to provide an offer to distribute the source to the changes (and follow through with it). Those changes are then licensed under GPLv2 as well. LKMs are an exception, where code which does not use GPLv2-only symbols can remain a proprietary binary blob. (GRsec is too tightly wound into the kernel to be an LKM)
Of course you can.
https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/tainte...
Edit:
---
Good point about the distinction between adding modules modifying existing source. It is an interesting question, actually and I haven't been able to find an authoritative answer on the subject.
A patch is a description of changes that would be made to a work, if they were made. Does it trigger the licence before it is applied to the source tree? On the other hand to generate a patch you would require the original source (even if you write it by hand you would still have to look at the source to determine line numbers). An you will probably have some bits of the source in your diff, but they are not being used for anything other than position information.
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 upfront to remove the proprietary code and try to reproduce the bug again.
End users can combine proprietary code with GPL code if they want to, because end users aren't bound by the GPL unless and until they distribute something covered by it. You don't even have to accept the terms of the GPL just to run the program[1].
A company distributing a proprietary module for the kernel may or may not be violating the GPL, depending on what it does and who you ask.
In contrast to the module stuff, GRSecurity is a set of patches to very low level parts of the Linux kernel itself. 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.
> 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 least if it's e.g. purely positional to elide context related issues). The result of applying the patch would not be distributable, but I'd think the patch itself would be fine.
The FSF's position that I have heard is that these modules, e.g. the nvidia module, is a GPL violation that the Linux maintainers have no desire to prosecute. In the FSF's opinion it's likely that a judge would say that user-does-the-link is subterfuge to try to get around copyleft.
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.
Distribute changes, it's all GPL. Don't distribute changes, it's whatever you want it to be. This does not change depending on how "distinct" your change is.
I'd argue that the code is always GPL, it's just that if you don't distribute it then the GPL doesn't have any restrictions.
> You don't even have to accept the terms of the GPL just to run the program.
Why do so many pieces of FOSS software—especially in their Windows or macOS distributions—have clickwrap that makes me accept the GPL to install them? Are they just misinformed?
> Why do so many pieces of FOSS software—especially in their Windows or macOS distributions—have clickwrap that makes me accept the GPL to install them? Are they just misinformed?
Misinformed, or just using installer tools that have a slot for an EULA, so they just stick whatever license applies to the software even if it is expressly not intended to be a use license in without thought.
Ah I see. So as long as they don't distribute the patch together with the GPL base codebase, they are good. Does that sound right?
This only applies to LKMs which use non-GPLv2-only symbols. If you change half the kernel, you are creating a derivative work, and it is therefore GPLv2.
grsecurity's patch set is significantly more involved than a single module.
This outcome makes me kind of sad. I bet there would be people willing to fund development of grsecurity and PaX in the open (i.e. with broken out patches, etc.), and there could plausibly be more money in that than in selling subscriptions.
the FAQ mentions "KERNSEAL, STRUCTGUARD" -- what are these? I tried searching on google but didn't find anything about either.
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.
They have, in fact, been generous in providing patches for free. Other people have been generous too. Generosity doesn't cancel itself out.
It must be particularly irritating in Spengler's case, because he works in a field where most of the best people make millions turning poorer versions of the same ideas into commercial products that only huge companies ever get to play with, while he spends his career arguing with upstream and taking shit from people on message boards.
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 merged.
In a comment [0] the PAX team says
> we never ever considered submitting grsecurity or PaX for mainline inclusion [...] anything similar in the past was user action, not on our behalf
I don't know how Spengler and PAX relate.
What's this, you suggest? Linus Torvalds and the kernel project in general not getting along with a serious security project? Why, I never!
Torvalds does great work. Spengler does great work. The kernel team does great work. The PaX team does great work. Torvalds is not always the easiest person to get along with. Spengler is not always the easiest person to get along with. Life is sometimes complicated. None of this takes away from anyone's achievements.
Thing is that the day Torvalds push a kernel that break some big name production environment is the day either the update gets ignored (effectively forking the kernel), or the big name goes looking for alternative platforms.
You see this back and forth happening over at Windows as well where continued backwards compatibility is weighed against future security.
Just look at the more restricted capabilities of anything WUP vs Win32 (never mind Win16).
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.
Where does one obtain up to date PaX patches other than rolled into grsecurity? I looked and couldn't find it.
See my other post -- those patches were pulled back when the -stable tree was pulled, although you could previously get them separately, if you were daring.
Every post on lwn or mailing lists by "PaXTeam" is quite obviously spender with another handle.
i think you're 'quite obviously' wrong ;).
paxteam is basically pipacs and spender is spender. You can read more about pipacs in phrack#66 [0].
PaX patches are no longer independently distributed.
That stopped last year at the same time the -stable patches were made private.
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 blame them.
> The important context here is that neither grsecurity nor PaX developers were involved in that mailing list discussion. The PaX Team's comment to the LWN article clears this up. We've never submitted the patches for mainline inclusion.
https://unix.stackexchange.com/questions/59020/why-are-the-g...
That is pretty much what Spengler says in the Stack Overflow question where this was asked directly.
Link for the lazy: https://unix.stackexchange.com/questions/59020/why-are-the-g...
It's not just the patches they provided for, it's also innovation.
The technologies these dudes developed are used in the vast majority of OSs outthere.
Instead of posting a cynical comment here you should thank them.
I mean, the grsecurity guys aren't the PAX guys.
They work together.
We have no real evidence of that other than it's what Brad Spengler says.
what, do you have 'real evidence' that we're the same person? if so i'd like to see it and also know how we pulled off our appearance at H2HC a few years ago. let me guess, we must have hired actors and bought them fake papers too? ;)
Are you serious? If yes, ask PAX Team, irc email, whatever.
You mean the freemail.hu email on a page that only appeared about a year after their last release?
Please don't do that, this is not Reddit, I'm sure you'll figure a way out to contact PAX Team.
Don't do what exactly?
Push your conspiracy teories.
It's no conspiracy theory that Brad both claims to not be paxteam, but has no problem making accounts with the username paxteam when he argues in comment threads.
Also, pedantically, this wouldn't be a 'conspiracy theory', since all I'm suggesting is that one guy is being disingenuous on the internet.
I thought the same thing. The Linux kernel has been "freely available" for a measly 26 years, and will continue to be so.
Why are the grsecurity patches not included in the Vanilla Kernel?
https://unix.stackexchange.com/questions/59020/why-are-the-g...
Original discussion from over a decade ago was more about clashing opinions, strong personalities, and anti-NSA sentiment (how SELinux ws handled). Grsecurity has always been very opinionated, and technically well implemented. That has never been the issue. In theory they also could have chosen to maintain only one version - in the official kernel.
To clarify some technical aspects, SELinux and grsecurity are not answers to the same problems, and they never meant to be. SELinux was always meant to implement things like multi-level security, bell-lapadula model, and extending 3rd party application with SeLinux roles, and the security daemon. Grsecurity has file oriented rbac system that was more approachable, and a variety of other patches (which are what grsecurity has been more known for - they have been always very excellent).
Knowing Spender, he was probably actually paid to stop. That's my guess. Not going to iterate on that.
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 have very specific "chunks" of functionality which are quite invasive, by design. This goes against the model the Linux kernel is developed, so the two development communities are simply mutually exclusive.
https://www.linux.com/news/google-developer-kees-cook-detail...
He's been working on this for a very long time.
> The problem is that getting things into small individually testable components > is literally anathema to the Pax/grsecurity model.
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.
Well I recall a somewhat recent case where you mentioned how there was one of features (I want to say it was the KASLR) that depended on another feature which still isn't in. You (spender in specific) mentioned on LWN how basically the feature was no good without the other 1/2 and the two changes were both somewhat invasive (in the Linux kernel context what Linus would consider invasive). I'm not saying you're wrong in any way or that you developed all 8+MB of code in 1 chunk. I'm saying you design your components to go together and depend on eachother, not to be split up individually and added sort of kind of willing/nilly.
Did I get that wrong? From reading Brad on LWN for literally years wank about Linux security (he's absolutely not wrong to complain), this was my take. Or it could be summarized as (this is satire):
PaxTeam: This is our code, it is open source, it is more secure than the dumpsterfire that is upstream, take it if you want it. Linux Upstream: That is nice, now break it into 1000 individual patches each independently git bisect-able. Also, can you change the interfaces of these design flaws in Linux and THEN entirely re-do your well tested patch to match the way we do code upstream and match the interfaces we would *like* Linux to have that we're going to expect you to code for us. PaxTeam: No, we want to do more interesting things like build more secure patches for Linux and look at pictures of cats on the internet, as it was designed to be used for. Linux Upstream: ...i don't quite get what you're arguing now... are you stating that when there're functional dependencies between components, we should somehow ignore them when incorporating them into a larger piece? say, the kernel should get a NIC driver before it got a network stack at all? if you're not arguing that then i don't see why different rules should apply to the security features we have...
as for your satire, it's just got one thing wrong, but that kinda kills the rest of it: we never said "take it if you want it" and thus we never embarked on the rest of that journey.
> 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?
That's not an argument against the current state of the pax/grsec being much more monolithic in architecture than the Linux kernel (I don't know if it is; just that that argument doesn't prove it's not.) Sure, the commits are small. 1000 small commits can add up to 100 small+simple components, or to 10 rather large+complex ones.
> define invasive
"Invasive", I believe, refers to how much of the kernel needs to be modified to upstream any given feature (regardless of patch size.)
The opposite of "invasive" is "isolated". 1000 lines of code in one module representing a new USB device driver, for example, is very non-invasive. It doesn't even need to be "hooked into" anything; it just puts a vendor+device ID into a database, and some existing logic will then detect devices with such IDs showing up on the bus and load the module in response.
Meanwhile, 1000 lines of code that make breaking changes (however small) in the ABIs or preconditions/postconditions of 100 different existing kernel functions, is an "invasive" patch. It requires a lot more testing than the USB driver to be accepted, because those 100 existing functions will be executed by a lot more people's machines than the USB-device module (which will only get executed on machines that have that device.)
i don't think you read carefully what i replied to so here's it again:
> The problem is that getting things into small individually testable components > is literally anathema to the Pax/grsecurity model.
nowhere does this talk about what the patch looks like. it talks about "getting things into small individually testable components" being "literally anathema to the Pax/grsecurity model". i.e., that decomposing the monolithic patch into composable pieces is somehow against our development model whereas said monolithic patch was developed exactly this way (which means the reverse process would reproduce these 'testable components'). that argument (my statement) directly contradicts Jeff's so only one of them can be true and as the author of the code in question i know which one is what ;).
as for invasiveness, you're only stating the obvious that there're more and less complex pieces of code yet both kinds (well, all kinds in the complexity spectrum really) can make it into the kernel. that is, this argument cannot be used against incorporating grsec on its own.
> as for invasiveness, you're only stating the obvious that there're more and less complex pieces of code yet both kinds (well, all kinds in the complexity spectrum really) can make it into the kernel. that is, this argument cannot be used against incorporating grsec on its own.
You asked for a definition, not an argument. Definitions are supposed to be obvious. Not every line of a reply has to be a rebuttal, just because one part is. :)
> which means the reverse process would reproduce these 'testable components'
The reverse process of how you built up the system (by committing changes), would break the the patchset down into commits. Commits might be patches, but they're sure not components.
A commit can change a line in the middle of a function in the middle of a random file anywhere in the kernel. A component is its own file/module/function that can be independently tested and verified and, most importantly, judged for how well the design-choices in its implementation solve the user-story they purport to solve, compared to other possible implementations.
A random one-line commit can certainly implement functionality—or can fix a bug—but it can't (usually) introduce a user-visible feature on its own. A series of one-line commits can, together, introduce a user-visible feature; but if they do, they need to be merged together into a single patch so that the design they implement can be seen, in order to be evaluated.
If you have take your codebase and just export all the commits as patches, each one might—as it probably originally did—just add one or two lines to the body of some function. But if all the commits necessary for a given feature end up combining into one big, monolithic blob of a patch—or end up extending several functions in the kernel into being large, monolithic functions—then the design of the feature is probably bad, and the patch will therefore probably be rejected.
What the kernel maintainers expect, in such a case, is for you to take your features and refactor them into independent subfeatures, such that each "patch that implements the feature" is fairly small. They expect you to do the same thing to your patchset that is done in a web-app when it is refactored into microservices: to make each component small enough, and non-interdependent-enough, that an argument over the design of the patch can involve each invested party writing their own version to demonstrate their idea; and where each component can be easily ripped out and replaced with one of the alternate designs, without affecting any of the other components.
For a good case of this already happening, look at OpenVZ. OpenVZ was a big, monolithic patch, that was never going to get upstreamed. It was refactored into the individual components of cgroups, the CPU freezer, memory quotas, and the addition of a number of namespace hierarchies. All of these components "add up to" something roughly equivalent to OpenVZ, but they're not OpenVZ. (In fact, they're effectively Docker; upstreaming them basically killed OpenVZ!)
> 1000 small commits can add up to 100 small+simple components
vs.
> Commits might be patches, but they're sure not components.
make up your mind, are components (whatever that means for you) composed of commits or not? :) as for commits vs patches, all commits are patches + description, but we use those terms interchangebly in the linux world with this understanding. in any case, i stand by what i said, we develop our code the same way upstream linux (or really any sane project) does. we're just not developing it for the purpose of inclusion, maybe that's the source of your confusion.
He could have been working on it for 26 years and still failed to get it in, which would only mean that he sucks at it.
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.
You realize he is a core kernel dev, right? He's splitting into pieces one at a time. When a part of Linux sucks and your patch changes it, upstream has you change the part that sucks and then adapt your patch to it. Makes things often take longer than necessary for new contributors.
To give you an idea of Kees's contributions:
Basically, he is getting as much of grsec as is feasibly upstreamable upstream as he's able to. Due to upstream Linux policies, the end results often turns out very different than the original grsec patches they were extracted from. Perhaps that is a better way of putting things?~/git/linux (master)$ git remote -v origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch) origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push) ~/git/linux (master)$ git pull Already up-to-date. ~/git/linux (master)$ git log --author="Kees Cook" --pretty=oneline | wc -l 701careful there, the author line doesn't imply authorship (if it does, the upstream kernel is already violating our copyrights).
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?
What do you mean, the Linux kernel isn't developed for free? Many contributors aren't paid.
And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam?
> What do you mean, the Linux kernel isn't developed for free? Many contributors aren't paid.
you're wrong, see item 6 in https://opensource.com/article/16/12/yearbook-9-lessons-25-y... though you might want to demand that Greg prove his identity first ;).
> And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam?
sure, come visit me in hungary and i'll take you to the local tax authorities and grant you access to my files. of course you'll have to prove your own identity first ;).
You mean that some developers are paid to implement things by companies? Fair enough, though I'd still argue it's not developed commercially because no one pays to get access to the result (they only pay to influence the result).
>> sure, come visit me in hungary
That'd be amusing, maybe sometime this summer? I'm kinda busy right now setting up my business :')
Let me know when you're around the Benelux, we could do the key-siging song-and-dance over a coffee or beer.
Then find someone interested in paying for its development?
Security improvements to Linux are great. However a hardened linux kernel is a derived work of the kernel.
It's unethical to take free software, build upon it, redistribute to customers but under contract agreements which prevent them from exercising their freedoms afforded by the license of the kernel.
If you think the linux kernel is crap, you are more than welcome to write your own kernel.
At most 80% of Linux contributors have jobs at software companies. That doesn't mean that all of them are paid for their kernel development, but at least 20% of contributors are definitely not paid for it.
As for grsecurity, 100% of the core grsecurity team (that work at "Open Source Security") are paid for their work. I will admit that I'm not fully aware of the interactions between PaXTeam and grsecurity, but I'd be shocked to hear that nobody at PaXTeam works at a software company related to security or kernel hardening.
and the source of those numbers is...?
> As for grsecurity, 100% of the core grsecurity team (that work at "Open Source Security") are paid for their work.
that's 100% false. both spender and me are developing our code in our free time. what the company is for is customer support, not R&D. shocked you are? :)
> and the source of those numbers is...?
GregKH, who you linked in a cousin comment. IIRC ~20% of code authors are not associated with a company. And if we go by your logic, then an even larger proportion are not "being paid for their kernel work". For a concrete example, I'm a maintainer of container runtimes at my current job but I have contributed code to Linux as part of my job -- does that count as "being paid" for it? In my mind, yes. In your mind, clearly not. But in GregKH's statistics I count as an employee of a company (not an independent).
But since you're too lazy to look at your own link, here's the article for 4.11 (https://lwn.net/Articles/720336/). 14% of changesets and 13% of lines changed are by people not associated with a company.
> that's 100% false. both spender and me are developing our code in our free time. what the company is for is customer support, not R&D. shocked you are? :)
"I work in an L3 support role on $technology, but any R&D work I do on $technology is completely unrelated." It's like you're not willing to acknowledge that the only reason someone would pay a two-person team for support on a kernel technology like grsecurity+PaX is that the same team is developing it. So even if your invoices don't have "development" written on them, the only reason you'd have customers is because of the fact that you are the main R&D behind what you're supporting.
can you quote Greg back on your "At most 80% of Linux contributors have jobs at software companies" because i don't see it in there? and you can add the source for your 20% while at it. on the other hand what Greg did say is this:
> The majority of developers are paid for their work[...].
that's not at all true for our case, that's all i pointed out.
> I'm a maintainer of container runtimes at my current job but I have > contributed code to Linux as part of my job.
if it's on company time (and thus dime) then yes, it's a paid job.
> 14% of changesets and 13% of lines changed are by people not associated with a company.
not really, more than half of each is 'unknown', so you can't tell one way or another. anyway, not sure what these are supposed to prove/disprove given what Greg himself said in the above quote.
> It's like you're not willing to acknowledge that the only reason someone would pay a two-person > team for support on a kernel technology like grsecurity+PaX is that the same team is developing it.
indeed it's not the only reason but since it's not your business (no offense meant just stating a fact), i can't comment on this further. what i did mean however is something different than the direction you veered off: our work isn't developed because it's paid for, it's a completely volunteer free time project (spender has a day job unrelated to this work, and until about a year ago i didn't have any at all in fact). that is, if you took the money out of the picture, our work would still continue to live on as it has for the previous 16 years. that is absolutely not true for upstream linux development (if it were then all these companies have been cheated out of their money they spent on developer salaries).
> can you quote Greg back on your "At most 80% of Linux contributors have jobs at software companies" because i don't see it in there? and you can add the source for your 20% while at it. on the other hand what Greg did say is this:
Sorry, it's 86% and 14% in Linux 4.11. It's literally in the link I posted. He gave a talk a few years ago at Linaro IIRC where he said "80% and 20%" as approximates but it seems like it's closer to 85% and 15%.
> not really, more than half of each is 'unknown', so you can't tell one way or another
Companies which pay their developers to work for Linux want to exercise their copyrights. It wouldn't make sense for them to conceal developers they are paying to work on Linux. I would argue more people who are listed as "from company X" are working outside of their work but have to declare their company ties due to IP worries.
> if it's on company time (and thus dime) then yes, it's a paid job.
Well, it's actually a bit more far-reaching than that. Most companies also claim that work directly related to your job (even not on "company time") is still owned by them (which you can assume means that's what they're paying you for). Maybe that's not the case in Hungary, but that is the case in America (and Australia where I am).
> if you took the money out of the picture, our work would still continue to live on as it has for the previous 16 years. that is absolutely not true for upstream linux development
I mean, Linux kernel development worked in this way for the first several years when it started. It doesn't really make sense to make authoritative statements about what is and is not possible in hypotheticals. Both Linux and grsecurity were developed for some time without direct income sources from most contributors.
All of the being said, I'm not sure why any of this is relevant. To me the statement "we are 100% unpaid for grsecurity R&D" sounds more like a semantic game than an earnest statement, given that you definitely are paid for grsecurity (whether it says R&D on the invoice is semantics IMO).
But w/e. You can pretend that you aren't paid for your work to seem more righteous. You don't get any sympathy points from me though.
> Sorry, it's 86% and 14% in Linux 4.11. It's literally in the link I posted.
you first quoted 80% and chided me for not reading the article linked to because it supposedly implied/had it in there. now you're moving the goalposts and point at a different article that i can't have guessed before you posted it.
> Maybe that's not the case in Hungary, but that is the case in America (and Australia where I am).
it's not necessarily the case there either. i had worked in both countries and always negotiated contracts that wouldn't have such overreaching clauses.
> I mean, Linux kernel development worked in this way for the first several years when it started.
exactly and you can see how much (or little, in this case) that achieved vs. what money did when it started to pour in. it's not at all hypothetical that if currently paid developers were stopped getting paid then the current pace of development would stop to a crawl (related example: look at gcc vs. clang/llvm after google/etc moved their developers from one to the other). easy test: would you continue to work on linux with the same pace/effort if your company stopped paying you for it? yes/no? if you answer yes then i also expect you to pay them back any past salaries you cheated out of them ;).
> Both Linux and grsecurity were developed for some time without direct income sources from most contributors.
in our case, it's not 'some time' but 'all the time'. that's the big difference which puts the original statement into a very different light:
> Meanwhile the kernel upon which their work is built has been provided for free for much longer
that 'for free' isn't at all free (money makes it happen) unlike our volunteer project (money doesn't make it happen).
> you first quoted 80% and chided me for not reading the article linked to because it supposedly implied/had it in there.
Sorry, I assumed that 80% and 86% were close enough that a reasonable reader would be able to see that I had mis-remembered the second significant figure for statistics I heard a while ago.
My apologies.
> easy test: would you continue to work on linux with the same pace/effort if your company stopped paying you for it? yes/no?
Yes (though my work is not generally kernel work, I would still continue to contribute to the free software projects I currently work on at the same pace).
> if you answer yes then i also expect you to pay them back any past salaries you cheated out of them ;).
... why? An employer pays you to solve technical problems that rise from their business. That doesn't mean that as an individual I wouldn't work on similar problems anyway, it just means that I get paid to work on specific problems rather than whatever I find important.
Effectively an employer pays you to change your priorities to match your employer's priorities. How much your priorities actually changed is not relevant.
Let me ask you a question. If one of your customers found a security issue in grsecurity or found that one of the features of grsecurity was broken, would you prioritise fixing it over whatever interesting feature you were working on "in your spare time"? If yes, then congratulations you're paid to develop grsecurity. If no, then I wouldn't pay you for support because I would have gained very little for my support contract.
> in our case, it's not 'some time' but 'all the time'.
You can continue to claim that, and I will continue to call bullshit. While you might be able to argue semantics and say "technically we never were paid for any particular features" I find such discussion disingenuous.
> puts the original statement into a very different light:
That statement doesn't say "developed for free" it says "provided for free". If it said "developed for free" I wouldn't agree with it. But by the same token I don't agree that there isn't a significant proportion of development that is not paid, and I don't lend credence to hypothetical predictions about how Linux would be developed without anyone being paid.
Despite what you say, Linux was developed for free for the first year or so and was mostly developed for free for several more years.
> Sorry, I assumed that 80% and 86% were close enough that a reasonable reader would be able > to see that I had mis-remembered the second significant figure for statistics I heard a while ago.
vs.
>>and the source of those numbers is...? >GregKH, who you linked in a cousin comment.
the article i linked to has neither number.
> An employer pays you to solve technical problems that rise from their business
not at all. an employer pays for stuff it can't get done for free. it's basic economics at least but i'm sure some shareholders would also have trouble understanding why the company would waste money that way. you just admitted that you'd gladly do the same work for free yet you somehow failed to tell that to your employer who are thus paying you for something that they could get for free and spend that money on other important things instead. that's doubly damaging to your employer.
> Let me ask you a question. [...]
it doesn't have to be a security bug and it doesn't have to come from a customer, we look at them with the same attention and priority regardless. money has nothing to do with it, we do it (and we have done so since the beginning) whether we're paid or not. i think you just have a hard time imagining that what customers pay for isn't R&D (though we're open to such contract work too).
> That statement doesn't say "developed for free" it says "provided for free".
yes and it's disingenous as to be able to provide linux 'for free' someone has had to pay for it which is very different from our situation.
> I don't agree that there isn't a significant proportion of development that is not paid[...]
you're arguing semantics ('significant' vs 'majority') with Greg at this point, i'll let you two work it out.
> I don't lend credence to hypothetical predictions about how Linux would be developed without anyone being paid.
fortunately you don't need to predict anything, just compare the code of linux 1.0 and 4.11.
> Despite what you say, Linux was developed for free for the first year or so and was mostly > developed for free for several more years.
i never said anything like that unless of course you can quote me back on it.
anyway, you're clearly more interested in insults and ad hominem than a rational discussion, so you can have the last word.
> yet you somehow failed to tell that to your employer
Were you involved in my hiring process? Are you my manager, or a stakeholder in my employer's business? How could you possibly know that I failed to tell my employer that?
> i think you just have a hard time imagining that what customers pay for isn't R&D
I don't have a problem imagining it, I just don't believe that your customers see it that way. If I was a customer of yours, I would expect that more R&D work would happen because I'm paying you (mainly because I firmly believe in free software businesses and that such R&D should be paid for).
> (though we're open to such contract work too).
Heh, so it's not 100% unpaid after all? ;)
> just compare the code of linux 1.0 and 4.11.
Wow, code gets better over time? Holy shit!
> so you can have the last word.
Gladly. :D