Besides a bit of lip service to code correctness, what can they do really?
They aren't going to move the kernel to a microkernel type design and besides, using advanced hardware features is out, because that would too closely tie the kernel to a single architecture. You could argue there is a business case for Intel and ARM to produce hardened Linux forks for their respective architectures as a form of competitive advantage, but since it hasn't happened in the past, I wouldn't be optimistic.
Also historical precedent has shown they aren't going to get tough on the vendor drivers. The kernel is filled with binary blobs (mostly firmwares), and as the article points out, vendor drivers are where the lion's share of the bugs are coming from.
The kernel does use hardware features for this kind of protection. It's done by using lightweight abstraction layers that are implemented per-architecture.
For example, accesses to userspace memory all go through copy_from_user() / copy_to_user() / access_ok() and related functions. Behind this, S390 implements separate kernel/user address spaces; x86_64 implements SMAP; ARM64 implements PAN.
it clearly can be done, there are a finite number of system calls. and while they aren't very well documented in some cases, the code is there for a reference.
but I think Linux is more than the kernel. If you break user land assumptions about filesystem layout, shared libraries, permissions, etc - are you in a better place as a 95% Linux with better security? From experience people aren't very happy with partial measures to make things linux like.
If you use the MS model (I really wish they had taken posix more seriously 20 years ago), you inherit all of Linux as model, with a different implementation.
If you leave the user/kernel boundary intact, have you improved the state of the world? To what extent are the security issues a result of the model and to what extent the implementation?
To answer my own question, I do like the car safety analogy. Since computers one day might driving cars at scale, I think the obvious strategic decision to prevent huge catastrophes is a simple one: Keep the cars un-networked.
True robustness arises from design thinking, not detail obsessing.
I'd like to avoid robo-cars that happily take the left lane on curves whenever they can't hear other cars coming the other way. After all there could be some Luddite tooling around in his ancient 2015 dumb-car. I never need to get where I'm going that fast.
They aren't going to move the kernel to a microkernel type design and besides, using advanced hardware features is out, because that would too closely tie the kernel to a single architecture. You could argue there is a business case for Intel and ARM to produce hardened Linux forks for their respective architectures as a form of competitive advantage, but since it hasn't happened in the past, I wouldn't be optimistic.
Also historical precedent has shown they aren't going to get tough on the vendor drivers. The kernel is filled with binary blobs (mostly firmwares), and as the article points out, vendor drivers are where the lion's share of the bugs are coming from.