3 ms·

Alternatively phrased, too bad upstream isn't able to work with Grsecurity.

throwawaylinux 5y ago
grsecurity has a vested interest in having (or being seen to have) better security than upstream. Maybe upstream is able to work with hundreds of different and competing companies and thousands of different people and clashing personalities and opinions, but they just happen to irrationally refuse to treat grsecurity fairly. Or maybe it's the simpler explanation that has more obvious motives.
- wahern 5y ago
  As I recall, one aspect of the tension originated from Linus' express hostility to pure security mitigations. IOW--and I don't know if this is the case today, especially after Spectre--Linus and a large part of the community were resistant to mitigations and code refactors that didn't actually add functional behavior, and especially if they were visible to userspace, harming backward compatibility. But those types of patches were precisely what grsecurity was pushing. So you basically had a fundamental clash of philosophies (independent of the clash of personalities) about whether the work grsecurity was doing was even valid from a software engineering standpoint. Arguably because of the relentless onslaught of exploits and growing enterprise influence, the Linux community slowly relented, but never with a mea culpa, AFAIK. A similar dynamic played out with /dev/urandom, where the Linux community and subsystem maintainers were adamant that the existing blocking and entropy accounting behaviors were crucial to security and non-negotiable. But now look where things stand--both are gone after 10-15+ years of debate. Again, without any mea culpas. Ditto for sandbox-friendly interfaces. Once upon a time any grievance that an interface which relied on /proc, /dev, or similar was suboptimal from a sandboxing standpoint (kernel surface area, headaches with chroots, etc) was met with derision. Eventually we got getrandom(2), and other recent application interfaces, like process descriptors, were revised so they were usable without /proc or similar. You could see alot of this play out on Slashdot, HN, etc as commenters frequently parroted Linux developers' talking points and assertions. There's plenty of blame to go around.
  - throwawaylinux 5y ago
    Many security mitigations have been merged into the kernel for a long time, probably longer than grsecurity has been around, but certainly something like NX-bit you could use as an example which was around the same time as early grsec (early 2000s). Sure Linus has been hostile or funny about such things at times, but that has not prevented him from being convinced or them from being merged.
- staticassertion 5y ago
  Right, that's why they gave away their work for free for decades?
  - throwawaylinux 5y ago
    What's why?
    - staticassertion 5y ago
      You're implying that Grsecurity's incentive to be safer than upstream means they won't cooperate. But Grsecurity made their patches freely available for the vast majority of their existence. I think it just shows ignorance of the situation to imply that they're only interested in making money.
      - throwawaylinux 5y ago
        > You're implying that Grsecurity's incentive to be safer than upstream means they won't cooperate. > But Grsecurity made their patches freely available for the vast majority of their existence. I didn't say anything about whether they made their patches freely available or not. Not sure what that has to do with what I wrote. > I think it just shows ignorance of the situation to imply that they're only interested in making money. I didn't imply that. I said they have a vested interest in perception of being more secure than upstream. Which they do. Replying with vague snark and going off on some wild tangent imagining things that I never implied isn't helpful if you can't address what I wrote. I didn't say anyone is to blame as such, nor does grsecurity have any requirement or moral duty to put effort into upstreaming their work. But if you look at the motivation there is a pretty reasonable explanation why they have not done so, in my opinion that's more reasonable and likely than the idea that it's upstream being particularly unfair or uncooperative to this one group.

grsecurity has a vested interest in having (or being seen to have) better security than upstream. Maybe upstream is able to work with hundreds of different and competing companies and thousands of different people and clashing personalities and opinions, but they just happen to irrationally refuse to treat grsecurity fairly. Or maybe it's the simpler explanation that has more obvious motives.

wahern 5y ago
As I recall, one aspect of the tension originated from Linus' express hostility to pure security mitigations. IOW--and I don't know if this is the case today, especially after Spectre--Linus and a large part of the community were resistant to mitigations and code refactors that didn't actually add functional behavior, and especially if they were visible to userspace, harming backward compatibility. But those types of patches were precisely what grsecurity was pushing. So you basically had a fundamental clash of philosophies (independent of the clash of personalities) about whether the work grsecurity was doing was even valid from a software engineering standpoint. Arguably because of the relentless onslaught of exploits and growing enterprise influence, the Linux community slowly relented, but never with a mea culpa, AFAIK. A similar dynamic played out with /dev/urandom, where the Linux community and subsystem maintainers were adamant that the existing blocking and entropy accounting behaviors were crucial to security and non-negotiable. But now look where things stand--both are gone after 10-15+ years of debate. Again, without any mea culpas. Ditto for sandbox-friendly interfaces. Once upon a time any grievance that an interface which relied on /proc, /dev, or similar was suboptimal from a sandboxing standpoint (kernel surface area, headaches with chroots, etc) was met with derision. Eventually we got getrandom(2), and other recent application interfaces, like process descriptors, were revised so they were usable without /proc or similar. You could see alot of this play out on Slashdot, HN, etc as commenters frequently parroted Linux developers' talking points and assertions. There's plenty of blame to go around.
- throwawaylinux 5y ago
  Many security mitigations have been merged into the kernel for a long time, probably longer than grsecurity has been around, but certainly something like NX-bit you could use as an example which was around the same time as early grsec (early 2000s). Sure Linus has been hostile or funny about such things at times, but that has not prevented him from being convinced or them from being merged.
staticassertion 5y ago
Right, that's why they gave away their work for free for decades?
- throwawaylinux 5y ago
  What's why?
  - staticassertion 5y ago
    You're implying that Grsecurity's incentive to be safer than upstream means they won't cooperate. But Grsecurity made their patches freely available for the vast majority of their existence. I think it just shows ignorance of the situation to imply that they're only interested in making money.
    - throwawaylinux 5y ago
      > You're implying that Grsecurity's incentive to be safer than upstream means they won't cooperate. > But Grsecurity made their patches freely available for the vast majority of their existence. I didn't say anything about whether they made their patches freely available or not. Not sure what that has to do with what I wrote. > I think it just shows ignorance of the situation to imply that they're only interested in making money. I didn't imply that. I said they have a vested interest in perception of being more secure than upstream. Which they do. Replying with vague snark and going off on some wild tangent imagining things that I never implied isn't helpful if you can't address what I wrote. I didn't say anyone is to blame as such, nor does grsecurity have any requirement or moral duty to put effort into upstreaming their work. But if you look at the motivation there is a pretty reasonable explanation why they have not done so, in my opinion that's more reasonable and likely than the idea that it's upstream being particularly unfair or uncooperative to this one group.