What is wrong about virtualization? It allows to run all existing software, it doesn't restrict the owner of the device, it is extremely flexible and reliable. And it can be fast, too.

see other comment, the author describes some issues with current hardware virtualization. kvm is also pretty good, but not perfect... and completely irrelevant with GPU pass-through enabled. =3

Which other approach to security do you consider reliable? Through correctness? Through obscurity?

https://blog.invisiblethings.org/2008/09/02/three-approaches...

Publicly documented encrypted mmu, as it is the only practical way to isolate contexts on parallel cores.

Or some exotic processor no one would ever sell successfully. =3

What would an encrypted MMU do differently?

Mitigates undetectable bleeding/contamination of information between parallel processes, cores, and or rowhammer etc.

Thus, writing a robust and secure OS may actually be possible by competent programmers in most compiled languages. Best of luck =3

But how does it accomplish that? And how can you guarantee it would solve those hardware issues?

The memory areas would appear as ciphertext to other processes/unprivileged-cores in most cases even when hardware has glitched up. If you are asking how they specifically implemented the mmu <-> unreachable key handling outside the OS, that information was never public if I recall.

I've often pondered how it was really implemented too. Best of luck. =3

"Why Multi-Threaded Code Can Sometimes Misbehave (Weak Memory Concurrency)" (Computerphile)

https://www.youtube.com/watch?v=E3hvLz717zM

Intel SGX/TDX and AMD SEV-SNP implemented that (although it was hacked the other day) and some clouds offer it.

Qubes OS was also shown to have inherent hardware virtualization sandbox vulnerabilities described by Joanna Rutkowska in an interesting lecture.

There is likely a PoC around someplace if people dig a bit. =3

Are talking about this? https://en.wikipedia.org/wiki/Blue_Pill_(software)

It happened in 2006 and never happened after that. I would consider it as secure as it gets.

Sorry, can't recall the exact lecture... It was only interesting as I was looking at a toy project to see if metastability issues were solvable. Practically speaking, it only proved the folks at Sun were very smart people choosing an encrypted mmu. =3

I am also surprised that capabilities weren't more widely implemented after mobile OSes demonstrated they are practical. I know Windows made a move in that direction with UAC but had to soften it due to user alert fatigue. So I guess having no legacy apps and a centralized repository helps.

I've recently been looking into Guix SD as a solution. Its package management is designed to keep programs independent of each other, so containers are cheap and lightweight. Trying out untrusted software is as easy as `guix shell --container --pure --no-cwd [program]`, which blocks access to the network, file system, and environment variables. Right now I'm adding more advanced capability management: limits on CPU, memory, storage space, network use, etc.

I use nix + bwrap, which gives a similar result. it works well enough, though I really ought to restrict reads to only the closure.

> I use nix + bwrap

In an automated way, or have implemented as hand-written wrappers? And regardless, have you published the code (and/or talked about how it works) anywhere? It'd be really nice to have a gentler onramp to sandboxing things, and nix should be well-placed for it.

an automated way, as part of a tree-based harness. I haven't published the code yet but should hopefully be able to soon!

Could you point me at a blog or github or something I can follow to see it if you do publish?