Spectre mitigations murder userspace performance

mitigations=off can only "patch out" some expensive instructions in the syscall path, or sometimes take a different path entirely, but it can't go back to the simple code before this was added in the first place. It also can't undo effects of compiler flags like -mindirect-branch which change the compiled code.

I haven't tested it recently, but when I looked at this more than a year ago, the numbers for a simple syscall (which doesn't do much work beyond the syscall mechanics itself) were something like 130ns, 250ns, 700ns for a "pre mitigation kernel", "new kernel with mitigations=off" and "new kernel with mitigations=on".

Some of the numbers have improved since then as better mitigations have been found, and/or improved CPU support for mitigations via microcode updates.

I've been of this opinion for a while now, not just because of performance slowdowns and security issues, but also just because of the way JS on web sites has been reducing usability in the form of popups, bitcoin miners, playing videos, sudden redirects to phishing sites and whatever crazy things are out there now.

I'm not saying get rid of JS, but treat it like it is - running code you can't trust. Web sites should start as largely static HTML documents that you read, and then if they need to use JS then they should be required to ask permission to do so, the same way any other executable code is managed in any other computing environment. That seems wild, but I think it's far less crazy than taking away a decade of performance improvements to the entire computing ecosystem by default so a broken security model can continue unquestioned.

“Car design has stagnated for decades. They emit massive amounts of greenhouse gases, and they’re not even all that efficient in doing so. But we can fix this! First, we’re going to use antimatter to power the engine, it’s 100% efficient and it has no waste products to boot,”

Your entire post is kind of like this for computer architecture. You rely on a lot of theoretical/academic ideas, which are cool, but nowhere near being practical (or even proven). Then there’s stuff like “we’ll solve security by formally verifying the OS and core software, and writing everything else in a memory safe language”…I mean yes, this obviously solves certain security issues. But there’s no clear path to get there, and we don’t even have the tools to formally verify certain software yet.

Then there are parts where you either undersell your knowledge on the topic or are seeming unaware of the current state of the art: dynamic linking for example. Your idea of memory mapping libraries is basically how dynamic linking works, except you call it static linking so you can handwave away the concerns that come with it. There’s also a lot of things that are unlikely to be efficient at all: pinning tasks to their own cores means they are unlikely to be doing much most of the time, using a ring buffer for message passing means that you’re going to be spinning on them (which is good for high-performance contexts, but most applications aren’t going to benefit from this). And so on.

I think overall you’ve actually done a fairly interesting job redesigning how a lot of HPC stuff works already, so I guess you can at least consider yourself on the right track for that kind of thing. But this kind of design isn’t really going to fly for general workloads, and you’re still relying on a lot of things that don’t actually exist beyond a research paper.