
Linus: Don't bother with grsecurity. Their patches are pure garbage - enedil
https://www.spinics.net/lists/kernel/msg2540934.html
======
rhblake
See Linus' follow-up [http://seclists.org/oss-
sec/2017/q2/596](http://seclists.org/oss-sec/2017/q2/596) for clarification:

> They aren't split up, there has never been any effort by you to make them
> palatable to upstream, and when somebody else _dioes_ try to make them
> palatable to upstream, you start crying about how people are taking
> advantage of your work (hah), and try to make them private instead.

...

> It's literally less work for people to re-implement things than look at your
> mixed-up patches, and YOU SEEM TO BE DOING THAT ON PURPOSE.

> Now, prove _me_ wrong. Start trying to integrate your work upstream, and
> send individual patches with commit logs that can be integrated.

~~~
uhhfcuvv
And the other guy's reply: [http://seclists.org/oss-
sec/2017/q2/597](http://seclists.org/oss-sec/2017/q2/597)

~~~
jlarocco
Seems like a waste of time for him to hold up that side of the argument. Even
if he's 100% correct, what's he going to achieve? The changes aren't going
into the kernel until they get past Linus, and for that to happen the patches
need to meet the same standards as every other patch. It's not like he's going
to lower the bar for one company.

~~~
sangnoir
> Even if he's 100% correct, what's he going to achieve? _The changes aren 't
> going into the kernel_ until they get past Linus

You are incorrectly assuming grsec guy wants the changes[1] in the mainline
Linux kernel - this would destroy a huge fraction of the value proposition. In
a follow-up message, Linus directly challenged them on how they intentionally
make their patches hard to upstream (and how they _complain_ about 'leeching'
if someone does attempt to upstream - talk about lack of self-awareness).

1\. He might not mind old changes, but the quicker the new patches get
upstreamed, the less valuable the patchset becomes for their paying clients

------
ajdlinux
The grsecurity team does have some valid criticisms of the upstream community,
and of course they've done some brilliant technical work, but spender is
unfortunately a pretty toxic community member who puts many upstream kernel
devs to shame when it comes to ability to flame.

It's a shame - there's a lot of good stuff in grsec/PaX, but I think the
upstream community is better off without the _people_ involved. The KSPP
effort to upstream grsec/PaX features is, of course, a good thing.

[disclaimer: upstream developer who lurks on kernel-hardening]

~~~
technion
Similarly, I used to run grsec on RedHat once upon a time. But the whole thing
just got too hard. When a critical update came, I could get a stock kernel
running "yum update", or I could play around building a whole new grsec
kernel.

I wish there was a way to take personalities out of this and let mainline
merge the useful parts of grsec.

------
Aeolun
So, just to confirm I see this correctly:

Grsecurity creates patches for issues in upstream, but their patches are too
fucking big/ugly, so nobody upstream really wants to merge them, and when
someone tries to fix em (take the important bits out), grsecurity complains
about them using their work.

Grsecurity then say they don't feel like doing a lot of work on their patches
when they're not paid to do it.

~~~
simcop2387
Along with that Grsec then says that if while the patch is GPLv2 if you
distribute them they'll never let you subscribe again to get the patch in the
future.

~~~
clhodapp
That's a pretty interesting loophole in the GPL: apparently (at least with
V2), it might be fine to impose consequences for exercising your rights while
technically giving them to you. It certainly violates the spirit of the GPL
even if it doesn't violate the letter.

~~~
AstralStorm
It does not impose amy restrictions on getting the code. You need to write a
bot to get status updates though.

Mailing list is not the code.

If he starts filtering on the web server or rejecting direct source requests,
he starts violating the letter of GPL 2.

~~~
clhodapp
I'm not sure that your claim about where the line is holds up: the GPLv2 never
requires you to give your source to anyone unless you first give them
binaries. That's why web sites don't have to give out their sources to
everyone who visits their site if they use a GPL library for instance.

In any case, if what you say is correct, the grsecurity team are still trying
to hold the threat of a more annoying experience over their users in order up
prevent them from exercising their rights under the GPLv2.

------
topkeker
Grsecurity wouldn't exist if Linux made security a priority. It doesn't,
because backwards compatibility and features is more important to them. It
doesn't mean because Linus says something so strongly on a subject is right or
wrong, he is generally abusive and rants and has for years.

Grsecurity is important to some people, not all, and vice versa for the
features and backwards compatibility crowd.

Personally I'd hope someone in Linus position would see both sides of the
fence, but he doesn't and always has some mouthy outrageous opinion. So this
is zero surprise.

~~~
ThrustVectoring
If backwards compatibility is broken, what you wind up with is a subsection of
users that out of necessity use versions of linux with _none_ of the updates
that secure the product. You can't just tack on security patches that break
user-required features willy-nilly, there's a big cost paid here.

------
doe88
For all his unfortunate abrasiveness one strength of Linus is and has always
been his capacity to see the big picture, e.g. that usually
compatibility/API,ABI stability/performances trumps extreme security measures
and also he has always been able to accomodate with big players/corps in the
industry.

~~~
ajarmst
I kind of find Linus refreshing, although I'm not sure that would survive
working directly with him. I think you're begging the question though: surely
compatibility/ABI stability/performance trumps extreme security (for some
values of 'extreme') for people and in cases where that is true. I happen to
agree with you and Linus on this (baring a known exploit of an unpatched
security bug), but that heirarchy is nowhere engraven in stone. If I always
recompiled a critical codebase, I wouldn't care as much about ABI
compatibility. If I'm always targetting a very specific platform, I don't care
about compatibility. If I'm sitting on millions of unused cycles in a single-
threaded realtime environment, I only care about performance to a certain
point. If I'm working on software to control a medical device or nuclear
reactor, my priorites around extreme security change.

You're right about that priority for the vast majority of the Linux user-base,
but that's a characteristic of those users and developers, not of kernel
software in general.

~~~
vacri
I've always found it weird that de Raadt is admired for being abrasive, and
Torvalds is pilloried.

I've always wondered, if the grsec people are such believers of 'security
above all else', why they just don't work with OpenBSD instead.

~~~
davidgerard
Until someone says "literally everyone uses ssh, you should donate" then watch
the excuses fly.

~~~
vacri
... because the linux kernel and git are awash with donations from users?

------
chrissnell
I'm an Arch user and I have no idea what's going on with security-focused
kernels these days. I was running the grsecurity kernel package but that was
recently replaced by a "linux-hardened" package that I had never heard of.
Then, a pacman update tonight installed a plain Linux kernel. It's very
confusing. Not unexpected for Arch but there is so little on the wiki about
this.

~~~
cyphar
The grsecurity patches have been made private. Although they are under the GPL
(because they are a derivative work of the Linux kernel), the company that
produces grsecurity engages in the unethical (and potentially illegal)
business practice of threatening to terminate customer subscriptions if they
exercise their right to distribute the patches.

In other words, no customer is going to distribute the patches because they
will have wasted money and lost access to updates. This is very reminiscent of
free speech chilling effects, and I'm surprised none of the copyright holders
in Linux (myself included) have teamed up to sue them.

Long story short, the general community (including distributions) no longer
has access to new patches making grsecurity useless for the community.

~~~
snuxoll
> the company that produces grsecurity engages in the unethical (and
> potentially illegal)

Unethical, probably - illegal, probably not. The GPL dictates what you can do
once code hits your hands (or binaries compiled with), it doesn't prevent
companies from selling it to you or what contract they do it under.

~~~
jopsen
Sure you can sell it, and under whatever terms you like. But you have to
_also_ provide the full source under the GPL, not under "the GPL with
additional constraints".

I'm no lawyer, but I highly doubt it'll hold. And buying Linux from them could
be very toxic as "GPL violation" => "termination of license" \-- and I'm not
sure how you go about getting a new license :)

~~~
infogulch
No, under the GPL you have the right to redistribute the source. You don't
have a _right_ to receive new patches or maintain any particular subscription,
that is a different consideration that you can maintain in a separate
contract.

~~~
jopsen
True,

But punishing people for exercising their rights, is quite similar to placing
restrictions on said rights.

I'm no lawyer, but you generally can't out-smart the law :)

~~~
infogulch
Of course you can be punished for exercising your rights. There is no better
example than free speech: you're free to say whatever you want, and your
customers are free to leave in response. The considerations of many contracts
include some form of restricting your rights in return for something.

IANAL either, in case that wasn't obvious.

------
a2tech
Strong words. Usually when Linus ways in so strongly on a topic he's pretty
certain of his take on it-it'll be interesting to see if there's further
discussion on both ends.

~~~
bitmapbrother
>How could they know that calling people clowns and their work garbage wasn't
payment enough?

>With no technical content coming from your end, there's no need to discuss
anything further -- don't waste your time because I won't reply.

I don't think there will be any further discussion.

------
protomyth
Reading one of the follow-up e-mail [http://seclists.org/oss-
sec/2017/q2/586](http://seclists.org/oss-sec/2017/q2/586)

 _Wouldn 't it be nice if you didn't demand free work of us in our free time?_
seems an odd line, but is there some context for the non-Linux person on what
is going on?

~~~
nisa
Don't count on this recount to be correct but as far I've followed it:

200x? \- grsecurity patchset is introduced and fixes a lot of bug-classes (!)
and introduces lot's of security improvements to the kernel that are ground
breaking and find their way in other systems like *BSD / Windows

200x-201x \- code and trademarks of grsecurity get ripped from embbedded
vendors - Linux foundations does nothing because they don't pursue GPL
violations \- no intent from grsecurity to upstream their work - at least
without getting paid for it.

2016-2017: \- Linux foundation founds KSPP and works on integrating basically
PaX/grsecurity into mainline - does not even ask grsecurity or PaX if they
want to get paid for helping but they are flamed at and bothered with
inquiries from devs \- according to grsecurity most of KSPP work is copy&paste
the grsecurity code without deeper understanding - introducing even new vulns
\- grsecurity only publishes patchset for current mainline kernel, no more
long term releases

2017: \- things are escalating, grsecurity patches go dark \- lot's of rants
and hate from all sites.

now: \- this mess.

I can see the point from the grsecurity guys - they produced ground breaking
research and it got ripped of everywhere and Linux foundation does not protect
it's interests because the corporations don't want GPL enforcement (not
related to the current dark patchset) and they don't even bother offering them
money for the work to integrate this stuff. The bad mouthing from Linus is
quite idiotic if you consider that most, if not all kernel vulns did not
affect grsecurity in the past years. It's also true that the patchset breaks
code depeding on the settings in plenty of ways.

Add lot's of rants and flames, big ego, personal attacks from grsecurity to
Linux devs and vice versa...not exactly professional. Not sure what was/is
going on beyond that.

At least that's some outsider Twitter/Mailinglist perspective. It's not black
and white and IMHO Linux Foundation and KSPP have some explaining to do.

~~~
michaelmrose
Their groundbreaking research was improvements that were directly derivative
of work shipped with a license that said all derivative works must be provided
under the same free license they received the work with.

Your tone seems to suggest that some obligation exists that some obligation
exists to do more than share the source to any improvements.

This obligation is wholly and totally imaginary. Its as if someone gave
another party an entire farm and in the contract specified that he could eat
some of the food that grew from it and that someone threw a fit when the first
party walked up and made a sandwich.

Seeing as there is no sane and legal way to require anyone to pay for said
patches the reasonable way to fund such an effort is to get the community to
voluntarily fund such an effort with whatever platform is most useful
preferably in advance.

It seems that they have instead chosen to rely on a mixture of manufactured
drama, illegal threats, and general unpleasantness to keep their efforts from
being well integrated with mainstream. While this remains so they can offer
definable value.

In the long run I predict bankruptcy and irrelevance for a company that few
care about now and none will care about later.

~~~
hitekker
Yeah, the parent's summary is tripe and implies that the GRSecurity is somehow
faultless in the drama they've vehemently instigated time and time again.

I'm having trouble seeing, apart from ignorance or misinformation, why anyone
would condone GRSecurity. The code is helpful but you wouldn't want the
authors in a position of authority over the operating system of a billion-plus
computers.

Right now, most arguments in defense of GRSecurity are simply: "Two sides are
arguing, therefore they're both wrong. Aren't I smarter for pointing it out?"

------
bubblethink
How are the Linux Foundation's funds allocated, and how much say does Linus
have in it ? Most of this boils down to lack of money and attribution for
grsec. Why didn't the Linux Foundation or Linus try to officially fund grsec
to upstream their patches ? KSPP is still costing money. How much would it
have cost to pay grsec directly instead ?

~~~
dm319
As far as I understand that is the opposite of how it works. The linux
foundation was set up to receive funds from big business contributors - like
Intel, Microsoft etc, who have an interest in the continuation of the linux
kernel and wish to pay for jobs which didn't have a source of funding (i.e.
Linus's job and other maintainer) and who wished to remain non-partisan. So
these companies provide both code and money. That money isn't meant to be
kicked back to profit-making companies as far as I understand.

~~~
KGIII
Also, probably because grsec's code doesn't meet the standards. By almost all
accounts, it pretty much sucks. I am unqualified to opine, but I trust the
opinions of who are qualified - by being the people who try to implement it.

------
amluto
Crikey! I seem to have set off this flame war, and I didn't even know about it
until I saw it here.

------
yuhong
So I wonder what happened in the end in the Wind River debacle.

------
madez
A genuine question: Why isn't it perfectly reasonable to accept to break
compatibility in order to increase security? Isn't that what we do in our
lifes all the time? When the authorities issue new fire safety regulations for
buildings, then that is breaking compatibility to the older building standard.
We still do it because there is good reason. Sometimes even old buildings need
to be retrofitted, and that is then what is done.

I don't get Linus in this point, and suspect so far that he is wrong, or that
I didn't get it yet.

~~~
geofft
It is, and he's wrong, and he's usually wrong when security comes up.

See also git using SHA-1: people warned him about this, and he argued
passionately and incorrectly that git doesn't use SHA-1 as an integrity
measure. He also argued passionately and incorrectly that SHA-1 was unlikely
to be broken and worrying about it was a waste of effort. And now other people
are doing a lot of slow work to dig ourselves out of literally every single
git repo in the world relying on a broken crypto primitive.

~~~
waynecochran
Git is not really using SHA-1 for encryption, just as unique hashes. I think
it is unlikely to get a collision in a non-contrived instance. Eventually git
will move off of SHA-1, but I imagine it will never matter.

~~~
tptacek
Nobody uses SHA-1 for encryption; it is a hash function.

~~~
waynecochran
It certainly has been used for encryption and probably still is. I wouldn't
lose any sleep hashing my passwords with it since most mortals couldn't break
it.
[https://en.wikipedia.org/wiki/SHA-1#Cryptography](https://en.wikipedia.org/wiki/SHA-1#Cryptography)

~~~
tptacek
That's a list of places where SHA-1 is used as a hash function in
cryptosystems.

------
vectorEQ
grsecurity, i like it. pretty secure for my machine. never had any breakage...
i think Linus should probarbly pay more attention to security issues in 'his'
os instead of being ratty about people taking it in their own hands to fix
it... if u want to know: you can increase the stack guard page for grsecurity
too, as theirs is also way small...

On the otherhand i dont see why a kernel doesn't track it's stack pointers and
heap allocations to see if there is overlap, its basic idea and stupid that
they ever dared to say this is not exploitable. Even though not many ppl seem
to have looked at it and/or done it, its plainly obvious there is an issues
with there being a possibility of overlap;. The stack guard page is a stupid
mechanism which at best causes an application crash (fking handle that shit
properly??) masked as 'security incident'....

that being said, linux, grsecurity, still my main choice, still much love for
linus and grsecurity folks. whish they could get along better and perhaps
someday think of actual solutions instead of infinite bandaids!

~~~
majewsky
> grsecurity, i like it. pretty secure for my machine. never had any
> breakage...

Pretty weak argument. I'm running stock Linux without grsec and I've never had
any breakage either.

> i think Linus should probably pay more attention to security issues

What makes you think that he doesn't? Also, there is a whole separate team
(the Kernel Self Protection Project) working on the issue.

------
romanovcode
I don't get it. Who would want to continue work with him with this attitude?

------
EGreg
The man doesn't mince words

------
43224gg252
The reddit thread is better:
[https://www.reddit.com/r/linux/comments/6j7saq/linus_torvald...](https://www.reddit.com/r/linux/comments/6j7saq/linus_torvalds_opinion_on_grsecurity/)

~~~
pawadu
I found the reddit thread much more interesting than the NH discussion...

------
known
BSD is more liberal than GNU/Linus

~~~
43224gg252
Why do you think this? Because they let people fork the kernel, patch it,
close the source, sell it, and never contribute anything back?

------
peterwwillis
This is just celebrity gossip/hype/flaming. Nothing new, interesting, or
intellectually curious here.

~~~
CalChris
I have to agree with this given the post. If Linus had a concrete example
rather than just his sweeping condemnation, it would be different.

~~~
moxious
If there had been concrete examples and such, rational argument (hopefully)
would have ensued, and HN would not have been notified about a completely
normal engineering discussion down in the weeds. But seeing condemnation and
drama works better for post material I suppose.

------
bitmapbrother
After reading the entire exchange between Torvalds and Spengler I must say
Torvalds was thoroughly trounced. It was like watching a child argue with an
adult. Spengler provided facts, justification, reasoning and proof while
Torvalds acted like a child and called him names and his work garbage. If
you're going to call someone out then at least have the decency to properly
address their reply instead of completely ignoring what they said and just
saying what you want to say.

------
dkarapetyan
Linus has cried wolf too many times. His outbursts about garbage patches are
no longer believable.

~~~
_e
Can you point to specific times? I want to dig into this more.

~~~
dkarapetyan
Google Linus rant. There are many examples.

~~~
cyphar
Crying wolf requires him to have been wrong (or lied). I think that GP was
asking you for evidence of _that_, not of evidence that Linus has ranted in
the past.

From memory, I can't recall a time where his ranting was not justified, but he
has been wrong a couple of times. Unless I'm missing something blatant, that
doesn't constitute "crying wolf" to me.

~~~
dkarapetyan
The parable of the boy crying wolf is not about lies but about desensitizing
your audience to what you are saying. I've read enough of the rants to know
there is very little signal to all the noise he makes.

The grsecurity stuff could be bad but I sure as hell am not gonna get my
analysis from Linus. If he acted more like a grown up then maybe but he
doesn't. He character assassinates and then says you are doing silly pointer
arithmetic. Can just mention the pointer stuff without shouting and screaming
at author of the patch.

The drama in kernel dev is a direct result of his abrasive approach. He
screams and shouts so grsecurity screams and shouts. Everyone else loses. The
kernel dev space needs less drama and more grown ups.

~~~
cyphar
> The parable of the boy crying wolf is not about lies but about desensitizing
> your audience to what you are saying.

... Because the little boy was lying. If there really was a wolf every time he
said there was they would consider him a brilliant scout rather than an
untrustworthy source of information.

It's strange that it's necessary to explain children's parables on HN.

> The kernel dev space needs less drama and more grown ups.

I don't disagree with that, I just don't agree with saying that Linus is
crying wolf. Because you don't appear to understand what it means.

------
ivanbakel
It's a struggle to respect the security opinions of someone who has actively
admitted that he thinks "[security] bugs are just bugs". [0] Personally, I
find it quite hard to respect Linus generally - his offensive personality is
clearly not something that would be appropriate coming from anyone else in any
community, but for some reason he gets a free ride for being a difficult
genius.

0\. [http://www.washingtonpost.com/sf/business/2015/11/05/net-
of-...](http://www.washingtonpost.com/sf/business/2015/11/05/net-of-
insecurity-the-kernel-of-the-argument/) N.B. The article is a bit deep in
technical inaccuracies - it calls Linux an OS, for example.

~~~
ajarmst
Nooooooo! Now we have to listen to the "what is an OS?" semantic flamewar!

