Makes sense. I disagree with him in that they can definitely have benefit over regular OS for security. The reason is relative simplicity and ability to easily integrate security tech in versus a whole OS with legacy compatibility issues. This was proven in KVM/370, then VAX Security Kernel, then MILS, then Nizza Security Architecture, and then people started leveraging Xen for similar reasons albeit without the same assurance. The NSA's pentesters repeatedly failed to breach some of these despite years of effort while the OS's... see Snowden leaks and TAO catalog.
Of course, I agree that VM's aren't necessary: one of many approaches one can use and don't get the job done by themselves. They are beneficial, though, as running security-critical components on a 4-12Kloc in kernel mode with mediated, simple interface should have way less impact than running it on 1Mloc+ with POSIX-style interface.
I haven't read it, but I assume the discussion was about sandboxing clients. From that perspective, any additional security would be defeated as soon as a client is able to affect the hypervisor or the host OS. So (according to Theo) if you can't write a secure host and/or client, the VM doesn't improve security.
While I agree with him on a lot of things, this isn't one of them; security is all about layers, and it's not like OpenBSD hasn't steered clear of other forms of sandboxing (like chroots and systrace). This doesn't mean that virtualization should be relied on exclusively or even near-exclusively as a defense (which is what I suspect Theo was more objecting to, along with the point of "well if you can't write a secure operating system, what makes you think you can write a secure hypervisor?"), but rather that it should be used as an additional layer on top of (or rather, underneath) a bunch of others.
It's like bulkheads on modern ships. Yeah, if you get a hole in your hull, you're gonna be in some (literally) deep water, but that bulkhead (so long as it's built right) could mean the difference between limping to the nearest harbor or sinking to the nearest seafloor.
Somehow back when Amazon had to reboot every EC2 server to fix a Xen bug, my "insecure" hypervisor-less server didn't require such action. I think I'll prefer to keep sailing without that particular bulkhead.
The reboots were because Amazon cuts a lot of corners in their Xen setup because instances are supposed to be "disposable". A proper VM cluster would use dedicated storage nodes that export over something like iscsi, which would require just transferring a memory snapshot, or would use the native, slower, disk snapshotting migration. But that's just one of many ways AWS is rather broken from an operations standpoint.
What you call a proper VM cluster has been pretty terrible from my experience as both a developer on an early cloud and a consumer of large government facing clouds.
Typically the network or SAN becomes oversaturated and the vm's shit the bed. AWS on the other hand was considerably more reliable and I'd argue they've made better decisions rather than cut corners.
Well true; even the RMS Titanic, with its fifteen bulkheads, was no match against an iceberg. Let's just hope that this new hypervisor for OpenBSD is built with better-quality steel :)
Also, it's worth mentioning that EC2 instances are meant to be ephemeral; Amazon doesn't provide any semblance of a guarantee that your instances won't reboot, and assumes that you intend for all your "machines" to be arbitrarily rebootable. Not saying that any hypervisor implementation right now is particularly good; only that Amazon isn't exactly the best representation here.
How many bugs have OpenBSD team found vs found in Xen? That would be a relevant comparison. From there, an assessment of exploitability of each given OpenBSD's attention to mitigation.
What you said, on other hand, was meaningless given that OpenBSD has had bugs that could lead to a crash. Real question is, "Do Xen or security-focused virtualization schemes (a) reduce number of vulnerabilities with impact of kernel-mode 0-days, and/or (b) prevent, contain, or facilitate easy recovery from OS- and app-level 0-days?" Prior experience in security-focused efforts show yes to both questions. Xen isn't one of them as the existence of the Xenon project shows. However, it's small size and improvements over time make it substantially less risky than an arbitrary OS + software combination esp if above layer is also addressed (eg MirageOS). Even Galois Inc.'s conservative teams are using it in some work.
and why can't you do that with containers or jails? or filesystem snapshots? or instant re-deploy to a known good state from ansible/puppet/salt/chef?
Just because there's a nice mouse-navigable GUI for entry level Windows admins doesn't mean it's a good solution.
if you need snapshots for doing updates it's because your software is fragile, undocumented, and you don't have a deployment procedure. Fix that, and upgrades will be easy and not scary.
Or you could have a consistent repeatable way of doing it across multiple apps and operating systems. I am not averse to your argument that doing it at the app level has benefits, but being able to do it at the VM level in a consistent way is going to be simpler when you expand beyond a handful of applications.
I agree that there is convenience to the execution controls VMs provide. But if you can't repeatably and easily stand up a replacement/duplicates of a system from configuration management and backups, then you don't actually have configuration management or backups.
Sure, to be clear I'm not arguing against those things, I'm just arguing that VM level snapshots and clones are also a tool in the operational arsenal and is in fact a very popular one that works well in practice.
KVM, VMware, and Xen all allow you to do a snapshot of memory as well as of disk. It's one of the tools used to migrate xen instances between nodes, for example.
Of course, I agree that VM's aren't necessary: one of many approaches one can use and don't get the job done by themselves. They are beneficial, though, as running security-critical components on a 4-12Kloc in kernel mode with mediated, simple interface should have way less impact than running it on 1Mloc+ with POSIX-style interface.