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.
To be even weakly fair, access is a component of security. If their patches break software, they would be breaking someone's security.
That is, backwards compatibility deserves that high bar. Ideally, you could get security without breaking things. If you can't, at least use care and take incremental steps to get things in.
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.
Some evidence in favor is that, at least in the early days of Linux, Microsoft took the same strategy of prioritizing backwards compatibility over security - and reaped the rewards by becoming extremely popular and extremely full of security holes. So clearly the strategy worked for MS. On the other hand, MS did respond and prioritize security, and was able to pull it off without compromising backwards compatibility too much. (For instance, last week's stack-clash vulnerability straight up doesn't exist on Windows because MSVC and the NT kernel have been doing the right thing with stack probes for years.)
But some real evidence against is that this whole backwards-compatibility thing is a kernel policy, not a userspace policy; no distro cares nearly as much. With the a.out to ELF transition and libc5 to libc6 transition back in the day, and to this day with OpenSSL versions, the GCC 5 libstdc++ ABI change, etc., there's not a ton of backwards compatibility in what binaries you can actually run on a real-world Linux system. It seems hard to believe that the kernel-to-userspace compatibility story is what made Linux popular, given the vast amount of userspace-to-other-userspace incompatibility.
I don't think it's "very" strong. It might just be "strong".
Rehashing MS's 90s-00s history of prioritizing security creates an unfair assumed comparison. Linux doesn't get to control userland the way MS does. I don't want to belittle MS's efforts, but the attack vector is a lot smaller in NT. Linux has way more features and use cases than the NT kernel ever has (maybe by an order of magnitude). We also don't have the complete picture on NT because of the source being closed.
> With the a.out to ELF transition and libc5 to libc6 transition back in the day, and to this day with OpenSSL versions, the GCC 5 libstdc++ ABI change, etc
You need to remember that Linux's use cases are way bigger than being able to build C binaries and stay forward with SSL. It's easy to forget, but Linux is hardly just servers, they are probably the biggest embedded foot print outside the no-OS or RTOS space, tons non-PC peripheral and consumer electronic applications. You're calling out one set of features that a huge swath of Linux consumers probably never touched for a decade (remember its only been recently that embedded applications have communicated over a network, or had to do so securely).
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.