That’s Meltdown, not Spectre.
Meltdown arguably does fit your description, but AFAIK the cost of checking permissions in the right place is almost zero, so it’s arguably better described as “we never realized it would be dangerous to not check permissions here” than “we skipped the check for performance’s sake”. (AMD processors were not vulnerable to Meltdown.)
Spectre, on the other hand, is sort of an inherent flaw of speculative execution (not related to permissions checks). Speculative execution itself is definitely a shortcut, but it’s a shortcut that’s crucial to the performance of all modern high-performance processors, with the result that nobody really knows how to deal with Spectre. Intel was apparently hit harder than AMD by side channel mitigations collectively, apparently because Intel was doing more aggressive speculation – but those mitigations are only partial. Both vendors’ processors are still vulnerable to Spectre attacks even with mitigations applied , and that will remain the case even on future processors, for the foreseeable future.
You could do that (see Singularity OS  and Midori ), but recently it was discovered that it wouldn't work on modern out-of-order CPUs due to Spectre .
How does this do anything to alleviate spectre and friends? Software isolation doesn't work (https://arxiv.org/abs/1902.05178), so the only protection you get is from process isolation, and I assume this doesn't change the OS mechanisms to enforce that.
> We don't need separate processes if the language we use is inherently safe (e.g., modern Common Lisp).
I note the year of the article, which was before Spectre and friends showed that this is not a reasonable assumption these days.
So does this mean LispOS is doomed?
Considering the recent "Spectre is here to stay" paper , can anyone comment on whether Firefox should be considered secure until the work on process-per-site lands (I believe they are working on it)?
The conclusion is beautifully scary:
"Computer systems have become massively complex in pursuit of the seemingly number-one goal of performance. We’ve been extraordinarily successful at making them faster and more powerful, but also more complicated, facilitated by our many ways of creating abstractions. The tower of abstractions has allowed us to gain confidence in our designs through separate reasoning and verification, separating hardware from software, and introducing security boundaries. But we see again that our abstractions leak, side-channels exist outside of our models, and now, down deep in the hardware where we were not supposed to see, there are vulnerabilities in the very chips we deployed the world over. Our models, our mental models, are wrong; we have been trading security for performance and complexity all along and didn’t know it. It is now a painful irony that today, defense requires even more complexity with software mitigations, most of which we know to be incomplete. And complexity makes these three open problems all that much harder. Spectre is perhaps, too appropriately named, as it seems destined to haunt us for a long time."
Worth reading the paper .