Comment by clhodapp
20 hours ago
It's only somewhat related to the article, but:
How do people feel about the hardware isolation provided by microVMs versus strong software isolation techniques like gvisor?
Right now, we put a huge amount of stock in "hardware isolation". If that starts falling to agents to any substantial degree, I wonder whether we might end up seeing a transition toward patchable software isolation, similar to the rise of software RAID that occurred a while back.
The general vibe I hear from security practitioners is that they (gvisor and Firecracker/Cloud-Hypervisor) are comparable. You generally do Firecracker if you can get away with it, because it's simpler and faster, but to do it well you generally need bare-metal hosts.
I think "hardware" vs. "software" is the wrong way to frame this. The big difference is between shared-kernel multitenant and guest kernels. gVisor (in some configurations) is like an 80% solution; a partially emulated guest kernel. I think the verdict is in on shared-kernel vs. not: don't share kernels between tenants.
The hardware isolation itself --- AMD-V, VT-X, &c --- has held up for almost 2 decades now. You never know, of course, but if you were going to place a bet it probably wouldn't be on hardware isolation failing before software did.
I think this is stated confusingly.
gVisor and Firecracker are nothing alike. gVisor is an application kernel written in Go. Application kernels will make your system much slower and can only solve a subset of security issues that would affect the kernel. They're like a kernel proxy of sorts.
Firecracker is a KVM virtual machine but made much more efficient. It's the most desirable of the two. Firecracker and KVM don't require bare metal, but in a virtualized environment they will require nested virtualization support. Nested virtualization is supported by just about every hyperscaler.
The reason KVM is preferable is because it provides strong isolation of the host kernel interface and independent emulation of host devices.
I've built systems out of both and they are quite similar, using different mechanisms as vectors towards the same outcome, which is to minimize shared kernel attack surface in untrusted workloads.
Firecracker doesn't require bare metal, but (1) you want it for performance and efficiency at scale and (2) you take a security hit for nesting.
6 replies →
[dead]