State of the Kernel Self Protection Project

Posted Sep 3, 2016 7:01 UTC (Sat) by mb (subscriber, #50428)
In reply to: State of the Kernel Self Protection Project by spender
Parent article: State of the Kernel Self Protection Project

>it's all ripoffs of grsecurity/PaX

The proper way to avoid "ripoffs" would be to upstream your code by yourself.
You don't do that? Well, in the Open Source world somebody else will possibly do it then.

State of the Kernel Self Protection Project

Posted Sep 3, 2016 13:09 UTC (Sat) by PaXTeam (guest, #24616) [Link] (20 responses)

the proper way to upstream our code would be for somebody to pay for that time.

State of the Kernel Self Protection Project

Posted Sep 3, 2016 13:59 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (7 responses)

> the proper way to upstream our code would be for somebody to pay for that time.

That's the rub. People are getting paid to do that. It just so happens to be people who have a history of doing it.

State of the Kernel Self Protection Project

Posted Sep 3, 2016 14:32 UTC (Sat) by PaXTeam (guest, #24616) [Link] (2 responses)

no, the rub is that while they're supposedly paid to upstream our code instead they end up ripping random stuff out without understanding what it does, how it works, how it was designed, etc. the end result is various ways and levels of brokeness which among others means that i still have to patch these ripped out parts in PaX to make them work properly (it's not a new phenomenon by the way, i've had to do this ever since NX/ASLR appeared upstream). i think that's not a history one would be proud of but then they're not wasting my money at least ;).

State of the Kernel Self Protection Project

Posted Sep 3, 2016 15:04 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

> no, the rub is that while they're supposedly paid to upstream our code instead they end up ripping random stuff out

You aren't pushing for that code to be directly upstreamed. That isn't necessarily a pleasant process and it is time consuming but since you aren't interested in doing that, you do end up losing control over how it is done.

State of the Kernel Self Protection Project

Posted Sep 3, 2016 15:12 UTC (Sat) by PaXTeam (guest, #24616) [Link]

> You aren't pushing for that code to be directly upstreamed.

i guess you've successfully concluded an infinite loop now: https://lwn.net/Articles/699300/

State of the Kernel Self Protection Project

Posted Sep 3, 2016 15:36 UTC (Sat) by Lionel_Debroux (subscriber, #30014) [Link] (3 responses)

The entry barrier for _significant_ security improvements to the mainline kernel - as opposed to e.g. KASLR, repeatedly shown to be easily defeatable - is very high.

As mentioned previously on LWN, e.g. https://lwn.net/Articles/662907/ , Linus himself repeatedly refuses some of the most powerful PaX defenses. Not only the hardware protections of recent high-end x86, x86_64 and ARMv7 processors he's mentioning aren't as powerful as PaX's (partially) software protections - see e.g. https://lwn.net/Articles/617945/ - but also, MEMORY_UDEREF and KERNEXEC work on processors about a decade older, and less expensive parts, which means that they could protect the vast majority of existing computers, rather than a tiny minority.
Emese Revfy once spent time, probably a significant amount thereof, making a large patch series constifying lots of needlessly writable, and therefore ripe for abuse, mostly "ops" structures in the kernel. The fact is that relatively few maintainers picked up the pieces.

Fortunately, the number of distros packaging grsec kernels is growing, and programs are slowly being improved / fixed - depending on one's POV - to work on PaX/grsec kernels (e.g. Docker wrt. grsec chroot hardening), which means that it's getting easier for users to get most PaX/grsec benefits. RANDSTRUCT is nullified by shared builds, but the other benefits, spanning a wide range of defenses, remain.

State of the Kernel Self Protection Project

Posted Sep 3, 2016 15:49 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> The entry barrier for _significant_ security improvements to the mainline kernel - as opposed to e.g. KASLR, repeatedly shown to be easily defeatable - is very high.

True but the politics here is unhelpful. The developers involved are not exactly pleasant folks to work with.

State of the Kernel Self Protection Project

Posted Sep 3, 2016 16:25 UTC (Sat) by spender (guest, #23067) [Link] (1 responses)

Are we talking about Linus and Greg KH?

-Brad

State of the Kernel Self Protection Project

Posted Sep 4, 2016 0:59 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

> Are we talking about Linus and Greg KH?

On either sides.

State of the Kernel Self Protection Project

Posted Sep 4, 2016 15:14 UTC (Sun) by mina86 (guest, #68442) [Link] (11 responses)

> the proper way to upstream our code would be for somebody to pay for that time.

It's free software, anyone can upstream it in any way they want regardless of being paid or not.

State of the Kernel Self Protection Project

Posted Sep 4, 2016 16:10 UTC (Sun) by PaXTeam (guest, #24616) [Link] (10 responses)

you're wrong, not anyone can upstream this much code without getting paid, you must be an early retiree with a few millions in your bank account to be able to work the thousands of hours 'for free'. but hey, prove me wrong, give it a try yourself and report back on your progress in a few years (or more realistically, never ;).

State of the Kernel Self Protection Project

Posted Sep 4, 2016 18:01 UTC (Sun) by ssmith32 (subscriber, #72404) [Link] (1 responses)

Confused. Is upstreaming the code without demanding payment such a unique and valuble ability that it should be respected and applauded, or so easy and simple that anyone could do it? You seem to be taking both positions?

State of the Kernel Self Protection Project

Posted Sep 4, 2016 18:42 UTC (Sun) by PaXTeam (guest, #24616) [Link]

you're confused indeed as i took neither of those positions.

State of the Kernel Self Protection Project

Posted Sep 5, 2016 0:43 UTC (Mon) by mina86 (guest, #68442) [Link] (7 responses)

I’m not commenting on practicalities.

But notice that in the past, people developing free software in their free time without being paid for it was the norm. To this day this in not out of ordinary. IIRC unaffiliated contributors are still single group involved in Linux.

Lastly, as far as I understand, a lot of the hard work has already been done (and PaX and grsecurity teams are to be thanked for that) so now pushing the code upstream is the easiest part.

There may be political reasons why it’s hard for the PaX and grsecurity teams to do that, but complaining about someone who puts up with Linus et al. to get the code into Linux is just childish.

State of the Kernel Self Protection Project

Posted Sep 5, 2016 17:39 UTC (Mon) by PaXTeam (guest, #24616) [Link] (5 responses)

i think you simply have no experience with upstreaming code of this amount and complexity and so don't understand the amount of effort needed for it. the thousands of hours i mentioned wasn't hyperbole, it's my estimate based on observing past progress (and often lack thereof) on various attempts. of course you can call me names all you want but that doesn't change the physical reality in which i simply don't have those thousands of hours of free time to spend (dare i say, waste) on upstreaming this code and clearly noone else does as all the real progress so far was made on company time.

State of the Kernel Self Protection Project

Posted Sep 5, 2016 18:16 UTC (Mon) by mina86 (guest, #68442) [Link] (4 responses)

I don’t understand your point then:

> the proper way to upstream our code would be for somebody to pay for that time.

This sounds to me that you’re claiming current upstreaming efforts are not proper because no one is paying for the time. Is that what you’re saying?

State of the Kernel Self Protection Project

Posted Sep 5, 2016 19:15 UTC (Mon) by PaXTeam (guest, #24616) [Link] (3 responses)

perhaps try not to take stuff out of context and also read the comment i replied that to :).

State of the Kernel Self Protection Project

Posted Sep 5, 2016 21:11 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

So... reading that, your complaint is that nobody is paying *you* in particular to upstream it?

This is sounding less and less high-minded by the minute.

State of the Kernel Self Protection Project

Posted Sep 5, 2016 21:15 UTC (Mon) by PaXTeam (guest, #24616) [Link]

not quite, try reading what i responded to again.

State of the Kernel Self Protection Project

Posted Sep 6, 2016 10:13 UTC (Tue) by paulj (subscriber, #341) [Link]

To be fair, even if "No one paid me to do it" is what PaX intended as a criticism, that's still quite acceptable. They spent a lot of effort on that work, and really it would be good if those who work on Linux get something towards food, shelter, etc. You can understand why he'd be miffed if others are now being supported to pick at their work and upstream bits.

E.g., every seems to be agreed PaX et al have done some good work on security. Wouldn't it be nice if some of the money going into hardening the kernel helped that work?

The question is whether the inter-personal issues at play can be overcome to make that possible. Whether PaX et al can co-operate, tackle the nits and implement review comments (which sometimes do no more than help give the reviewers a shared sense of participation and value - but we socio-insensitive techies often don't perceive the soft, socio-politics, sigh), etc. Whether the other side(s) could get over their hostility, etc. ?

Shame really for everyone, inc. the users.

State of the Kernel Self Protection Project

Posted Sep 9, 2016 14:13 UTC (Fri) by thestinger (guest, #91827) [Link]

> IIRC unaffiliated contributors are still single group involved in Linux

Lack of known affiliation doesn't mean they aren't being paid to do the work. It can still be part of their full-time work or a contract. They may also be self-employed in a way that they earn money from landing code upstream. A subset are certainly volunteers but there aren't meaningful numbers on that.