That's a nice link. It also has absolutely zero to do with any of the specific defenses that I mentioned, and the fact that upstream Linux doesn't have them -- again, my point is there are tons of things upstream can still do to harden the kernel, before getting to breaking userspace, despite your initial claim to the contrary. The point isn't "you must adopt the grsecurity patches" or the politics around why grsec won't help upstream. The point is that these meaningful improvements actually exist, and they are not available. It's simply factual Linux is way behind what's possible.

Furthermore, I really don't see how that link is relevant, given most of the more recent security features that went upstream, as well as many of the ones that will come in the future -- all originate in part from grsecurity anyway. Apparently, your position is that the kernel developers have already done all they can, and any further improvements else will break userspace, so systemd is definitely totes the #1 biggest problem now, everybody (non sequitur, but whatever). But when I bring up the defenses they could implement, but haven't yet, from the same source of the previous ones -- apparently I'm just doing some irrelevant posturing, or something? I find that funny. Maybe in 5 years when they've poorly ripped off more features and are still behind, you'll be moving the goalpost and saying "Any further improvements would break userspace", and it still won't be true in the slightest. :)

PAX_REFCOUNT is a non-breaking addition that would have stopped CVE-2016-0728 completely, for example, had it actually existed upstream -- it will soon enough, at least, as someone is working on it by porting the grsecurity patches.

The reality is very simple, even if you don't like it: upstream Linux is just bad at meaningful exploit mitigation, in many ways, and they have trailed behind what's possible for literally years. I'd also argue that some kernel developers seem to just have a complete, fundamental misunderstanding of what the point of the mitigations are, which is damning. One guy on the dev list argued with Kees Cook that people shouldn't bother with this shit, because we don't need to help "those bastards with proprietary modules be more secure" (Kees works on Android, so proprietary modules are just a fact of life, grsec improving their security simply being tangential), or help the people with out of tree kernels like the grsecurity team. It had apparently never dawned on him that mitigation tech could stop exploits that appear in the future. Like PAX_REFCOUNT stopping an exploit that would only appear in the future as time went on. This is mind-blowing as a position, for a developer of what is ostensibly one of the most complex projects in the world.

Anyone who has followed the grsecurity project for a while is pretty well aware of why they don't bother with upstream, and aware that upstream mostly reinvents their work, poorly. In any case, the given link is still irrelevant.

I'm going to go out on a limb and say you don't actually know much about modern memory corruption defense, or the landscape of modern kernel security and how it has moved forward over time, if this non-reply is your only answer to the examples I listed...