"""> Virtualization seems to have a lot of security benefits.
You've been smoking something really mind altering, and I think you should share it.
x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit.
You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.
You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it.
That's all x86 virtualization is. """
The only hardline view on security you'll encounter in the wild is "security is practical in our computational environments"[1]. Only half-joking here.
My reading of Theo's quote is merely "the combination of x86/IA32/AMD64 and virtualization gives little to no factual security benefits, and plenty of pitfals".
I don't see Theo as being a hardliner about security, just meticulous about good engineering practices - as per OpenBSD's usual standards - and facing the problems & risks as they are.
[1] examples: "Rust/Java gives you security", "shortlisting the only allowed actions by end-user application gives you security", "hardcore firewalls give you security", "virtualization gives you security", "advanced architectures like Burroughs' give you security".
The new class of attacks we now see target any type of shared code execution environment. OpenBSD is as vulnerable to this as anything else.
Reminds me a friend who worked on Javascript in the early days said it was the only thing that had any hope of providing minimal security at the time. Because Windows 3.1 and 95 +0x86 was a security trashfire.
[1] http://www.tylerkrpata.com/2007/10/theo-de-raadt-on-x86-virt...
[2] https://www.openbsd.org/faq/faq16.html
[1] probably isn't the best source out there, I was in a bit of a rush to find it but that is indeed the quote! Gotta either love or hate Theo I guess!
1. There's no way in hell that a bunch of VMs running on one physical server is more secure than a bunch of different physical servers each running an OS. If there were architectural hooks for those VMs to provide additional security beyond what the host OS provides, then an OS like OpenBSD would already be making use of it.
2. Running a bunch of VMs on a single physical machine is certainly cheaper.
3. People who are in favor of the cost-cutting are claiming that there's a security benefit to sell more stuff.
Am I right?
If so, how does that stance jibe with the research that Qubes is based on?
I think security guarranties are better if you follow practices of a little selfcentered project such as OpenBSD (run only trusted code) than if you follow practices of QubesOS (running whatever untrusted code you desire in Xen domains and relying on VM separation).
We will most likely see a continued divergence between "consumer silicon" which is designed for speed in a single tenant environment on your local desktop or laptop, and "cloud silicon" which is optimized to protect virtualization, be power efficient, etc. I'd predict that this will actually lead to increased efficiency and lower prices of cloud resources rather than the "death by a 1000 cuts" that you are proposing.
Even if there's no opportunity to switch away, eventually you bleed your customers dry and put them out of business. You will typically always aim to price your offering at the equilibrium point where loss of custom increases faster than the increase in profit, and vice versa.
One situation in which an increase in your costs can be good, is if the same increase applies more to your competition. But, in this case multi-tenant cloud is hit harder than the competing alternative of private infrastructure.
Am I totally misunderstanding this? Someone please correct me if I'm wrong.
I don't think you don't need to go this far. You can probably get away with circuit switching small blocks of hardware, and fully resetting them between handovers. Although you'd have to ensure sufficient randomisation / granularity to destroy side channels in the switching logic.