Useful additional context/counterpoint:
(I was shocked when I just googled "exploit mitigation" and all I got back was infomercial articles by Symantec and Sophos etc. Scary. So for people browsing here and googling terms, dig deeper!)
I think we need exploit mitigation _and_ process isolation _and_ the principle of least privilege.
Fwiw, the twitter article mentions capabilities. Something I can pontificate about! I've been lucky enough to chew a _lot_ of cud with some GNOSIS/KeyKOS/caps luminaries etc. And we were still mega-fans of the Capability Object Model but _not_ believers in Capability-Based Addressing. When I did some design work with Norm Hardy on the Mill CPU I designed a temporal variant of the former that protected ... memory. OpenBSD is actually damn serious about the former. The twitter link is advocating the latter as a fix for something?
I would love to chat with anyone who wants to convince me that Capability-Based Addressing _works_ or is workable. I know that others from KeyKOS etc moved more towards the caps addressing. Anyone want to read up on some of this stuff, I warmly recommend the papers and talks for CHERI, even though I'm not a fan of caps addressing.
Is it possible to get this resource on a single page? Having to click through each page just to read a sentence or two is quite cumbersome.
I also highly recommend checking OpenBSD's events page for additional slides/papers and videos.
A quick googling finds this https://events.yandex.com/lib/talks/103/ which is, I think, Theo presenting the slides on part II.
Paper: https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201406...
"Motivated by contemporary security challenges, we reevaluate and refine capability-based addressing for the RISC era. We present CHERI, a hybrid capability model that extends the 64-bit MIPS ISA with byte-granularity memory protection."
Capability-based addressing https://en.wikipedia.org/wiki/Capability-based_addressing is hardware that implements 'fat pointers' that point to ranges of memory so its not possible for a program to address memory it shouldn't. Basically, it forces programs to be 'memory safe' https://en.wikipedia.org/wiki/Memory_safety even if written in memory-unsafe languages such as C.
http://www.cs.washington.edu/homes/levy/capabook/index.html
The surviving, capability architecture is System/38 -> AS/400 -> IBM i. A side effect of better architecture is that they are also incredibly reliable. One person here described them as the tanks of their company's servers.
Despite what people might think, OpenBSD only enables mitigations that have an acceptable overhead. And because of this work, for example, OpenBSD/arm64 kernel has _zero_ ROP gadgets at runtime, and OpenBSD/amd64 common scripts like ROPGadget.py will often fail to find diverse enough gadgets to even exec a shell.
https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf
https://www.openbsd.org/papers/asiabsdcon2019-rop-slides.pdf
But most users' exposure to vulnerabilities comes in the window between patch released and patch applied. It takes some amount of time to reverse a patch and develop an exploit, and users are racing against that time. The difference between just 24h and 48h can matter, no?
Which nowadays is only available on Solaris on SPARC, iOS and eventually Android (given Google's collaboration with ARM).
And even it is still isn't 100% bullet proof, it is better than not having it at all.
This is not an accurate statement. Oracle is still actively developing Solaris 11.4 and releasing regular updates. They plan to support Solaris and SPARC systems to at least 2034. This does not sound very dead to me.
Intel has dropped MPX support from newer generations, given that their design was buggy and no one bothered to actually make use of it.
So they decided that improving the design wasn't worthwhile.