gVisor emulates a kernel in userspace, providing some isolation but still relying on a shared host kernel. The recent Nvidia GPU container toolkit vulnerability was able to privilege escalate and container escape to the host because of a shared inode.

Styrolite runs containers in a fully isolated virtual machine guest with its own, non-shared kernel, isolated from the host kernel. Styrolite doesn't run a userspace kernel that traps syscalls; it runs a type 1 hypervisor for better performance and security. You can read more in our whitepaper: http://arxiv.org/abs/2501.04580

So it's a lightweight way of running docker images inside a virtual machine?

Yes, precisely. This also provides container operators with the benefits of a hypervisor, like memory ballooning, and dynamically allocating CPU and memory to workloads, improving resource utilization and the current node overprovisioning patterns.

Thanks for the explanation. So you are using virtualisation-based techniques. I had incorrectly inferred from other comments that you were not.

I skimmed the paper and it suggests your hypervisor can work without CPU-based virtualisation support - that's pretty neat.

Many cloud environments do not have support for nested virtualisation extensions available (and also it tends to suck, so you shouldn't use it for production even if it is available). So there aren't many good options for running containers from different security domains on the same cloud instance. gVisor has been my go-to for that up until now. I will be sure to give this a shot!

So it’s a VM?

It's Xen, and they even explain why it's not KVM here: https://github.com/edera-dev/krata/blob/main/FAQ.md