Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 19:00 UTC (Wed) by ms-tg (subscriber, #89231)
Parent article: Ripples from Stack Clash

Hi Jonathan,

Am I the only one that is increasingly finding it hard to see how Brand Spengler / PaX / GrSecurity / Open Source Security / whomever is or was in the wrong on any of this?

Sure, it's true that their scorched-earth style of discourse is/was not helping their points of view to be heard. But seeing how all this has played out, it doesn't look like the mainstream kernel community, Linus included, came off a whole lot better, does it?

Has anyone proposed the following modest commercial model: Someone, let's say Red Hat, pays a sizable annual contract for the services of PaX. In return, PaX works with someone at Red Hat whom they essentially teach, full-time, all the details of all their threat models, vulnerabilities, and protective measures, as understood and implemented by PaX? I would imagine that such a person would then have a fairly good opportunity, in their full-time role as such, to craft these ideas into kernel patches which are both (a) acceptable upstream, (b) signed-off by PaX as fully providing all protection claimed, and (c) unambiguously citing PaX as the source of the ideas behind them?

In other words, could it become as simple as: pay PaX to sit down and work with someone full-time to upstream their ideas, and also pay that other person to act as the full-time intellectual and implementation intermediary between the two difficult cultures of PaX and upstream Linux?

Just a thought...

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 19:51 UTC (Wed) by riel (subscriber, #3142) [Link] (4 responses)

Kees Cook and others are working to upstream the good stuff from the linux-hardened and PaX/grsecurity trees. The maintainer of the linux-hardened tree is helping out with this, too.

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 20:09 UTC (Wed) by ms-tg (subscriber, #89231) [Link] (2 responses)

Yes, but...

Isn't the "missing part", that they are making patch sets that end up acceptable for upstream approval, but not necessarily approved by PaX as being complete and fully understanding the problem, and accounting for every detail that is changed from the original solution and why that doesn't violate any assumptions about the threat model?

In other words, isn't the problem that there's no formal role assigned here for PaX itself? And wouldn't they be willing to play that role if
(a) they were paid for it, probably by Red Hat
(b) they're job was to approve the interpretation of the patches, or clearly explain what was still not right
(c) they were clearly credited for originating the understanding of the vulnerability and/or hardening solution?

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 20:15 UTC (Wed) by andresfreund (subscriber, #69562) [Link]

That sounds like the most likely outcome of that would be zero progress. grsecurity has a commercial interest in *not* getting this stuff into core. Several people associated with grsec have a communication style clearly aimed at not resulting in actual cooperation. They don't approve of working on things incrementally. Why would it be a good idea to give them veto powers - and that's pretty much what you're suggesting.

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 20:27 UTC (Wed) by pizza (subscriber, #46) [Link]

> Isn't the "missing part", that they are making patch sets that end up acceptable for upstream approval, but not necessarily approved by PaX as being complete and fully understanding the problem [...]

You're missing a crucial point -- In many ways, there are fundamental conflicts between the needs of upstream and the needs of a hardened patchset. Implications include API changes, performance regressions, maintainability, and so forth. I'm not saying that either side is inherently _wrong_; just that there are legitimate areas of disagreement that could easily result in incomplete bits being mainlined.

Another thing that the core kernel maintainers have repeatedly (and IMO correctly) prioritized is a maintainer's ability to play well with others. None of them exist in a vacuum.

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 29, 2017 11:28 UTC (Thu) by paulj (subscriber, #341) [Link]

That's been done in a way that doesn't benefit spender, PaXteam, etc., at all. Which has made the situation worse. Not really surprising that paying one set of people to work on other's people code, leaving those original authors out in the cold, would make that other set of people even more antagonistic.

Yes, I know there's lots of people factor issues here, but... there is clear value in their security work regardless, and the above situation is highly sub-optimal (for users esp.).

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 20:22 UTC (Wed) by pizza (subscriber, #46) [Link]

> Has anyone proposed the following modest commercial model: Someone, let's say Red Hat, pays a sizable annual contract for the services of PaX.

As the saying goes, it takes two to tango.

It's my understanding that Pax/etc has refused to pursue this of their own accord, categorically rejected others trying to arrange this for them, and has set fire to just about every bridge in the process.

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 28, 2017 20:28 UTC (Wed) by josh (subscriber, #17465) [Link] (3 responses)

It makes a huge amount of sense to pay people to do this work, which is what's being done. However, if the goal is to make the upstream kernel secure, then rather than selecting people with a history of not collaborating with upstream and intentionally antagonizing everyone around them, it makes more sense to select people demonstrably capable of doing so.

Take a look at the tantrum-level spitefulness on the CVE-related mail and ask yourself if that's who you'd want to employ. There's a reason that the community has carefully weaned itself away from dependencies on people like Joerg Schilling and Ulrich Drepper, in favor of people who work well with the community.

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 29, 2017 9:55 UTC (Thu) by nhippi (subscriber, #34640) [Link] (2 responses)

When KSPP started to materialize, it would have made sense to Linux Foundation to ask Brad to do it. Even if they didn't, Brad should have seen the writing in the wall and proposed to do it himself. We don't know why exactly Brad is not getting the KSPP money, and instead some other people are paid to upstream Brads code. But chances are "not being nice to your potential future customers" played a big part in it.

Linus is not much better - which is especially bad because some people think the success of Linux is because of his style and LKML culture - rather than despite of it.

KSPP

Posted Jun 29, 2017 13:44 UTC (Thu) by corbet (editor, #1) [Link]

It is worth remembering that KSPP is not a Linux Foundation project, and there is no "KSPP money" slush fund that the LF could have directed differently.

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jul 6, 2017 17:18 UTC (Thu) by Wol (subscriber, #4433) [Link]

> Linus is not much better - which is especially bad because some people think the success of Linux is because of his style and LKML culture - rather than despite of it.

I think you'll find Linus is a *lot* better.

Yes he can have a potty-mouth. But he rarely uses it, and mostly when the other guy has been demonstrably stupid. Also the other guy is usually well-known to Linus.

There's a big difference between a bully picking on everyone, and a playground scrap between friends. Linus is respected for his technical judgement, and his ability to keep out of things while dropping technical bombs into other peoples' conversations. There's two things - being able to tell someone politely that their code is wrong because ..., and also to be able to tell someone that their code "does not feel right". Linus has that ability in spades, while unfortunately Pax et al don't have those people skills ...

Cheers,
Wol

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jun 30, 2017 17:13 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> let's say Red Hat, pays a sizable annual contract for the services of PaX. In return, PaX works

I don't think you are in any position to negotiate working conditions for GrSecurity developers, they are capable of doing that themselves, and you aren't the first person to propose an arrangement like this, if GrSecurity developers really wanted to work this way this would be a solved problem. Since you are starting with a fantasy assumption the rest of your idea doesn't really matter.

Increasingly hard to see how Brad Spengler is/was in the wrong

Posted Jul 2, 2017 15:34 UTC (Sun) by jospoortvliet (guest, #33164) [Link]

So the PAX st all team was offered money to upstream their work and was uninterested? That explains their aggression towards the kspp efforts i guess...