I 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...
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...
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.
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?
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.
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.