Cool idea, but Xen seems like an odd choice? I mean, KVM gets so much more attention from a broader set of developers, doesn't it? What makes Xen a better fit for this?
> We believe that the Xen hypervisor architecture better suits the needs of our project. Xen hypervisor is very
small comparing to Linux kernel, which makes it substantially easier to audit for security problems. Xen al-
lows to move most of the “world-facing” code out of Dom0, including the I/O emulator, networking code and
many drivers, leaving very slim interface between other VMs and Dom0. Xenʼs support for driver domain is
crucial in Qubes OS architecture.
KVM relies on the Linux kernel to provide isolation, e.g. for the I/O emulator process, which we believe is not
as secure as Xenʼs isolation based on virtualization enforced by thin hypervisor. KVM also doesnʼt support
driver domains.
Ah, thanks, that clarifies things, and it makes sense. Though I imagine there's pain with hardware support vs. Linux which runs on everything and can pass through access to KVM VMs. I mean, it seems like GPU support would be challenging, in particular.
Circa 4.1, I really loved the idea of Qubes VM-level app isolation similar to Kata Containers in service/server-land but experienced showstoppers with configuration management, disaster recovery (backup & restore even with the built-in helpful stuff), and privileged stuff like networking, USB, custom background services, and hardware support. There was too much undocumented magic tweaking necessary to make a physical laptop usable. ): Maybe it's improved?
Cool idea, but Xen seems like an odd choice? I mean, KVM gets so much more attention from a broader set of developers, doesn't it? What makes Xen a better fit for this?
From the architecture spec doc:
> We believe that the Xen hypervisor architecture better suits the needs of our project. Xen hypervisor is very small comparing to Linux kernel, which makes it substantially easier to audit for security problems. Xen al- lows to move most of the “world-facing” code out of Dom0, including the I/O emulator, networking code and many drivers, leaving very slim interface between other VMs and Dom0. Xenʼs support for driver domain is crucial in Qubes OS architecture. KVM relies on the Linux kernel to provide isolation, e.g. for the I/O emulator process, which we believe is not as secure as Xenʼs isolation based on virtualization enforced by thin hypervisor. KVM also doesnʼt support driver domains.
Ah, thanks, that clarifies things, and it makes sense. Though I imagine there's pain with hardware support vs. Linux which runs on everything and can pass through access to KVM VMs. I mean, it seems like GPU support would be challenging, in particular.
GPU support and passthrough work fine IME
Circa 4.1, I really loved the idea of Qubes VM-level app isolation similar to Kata Containers in service/server-land but experienced showstoppers with configuration management, disaster recovery (backup & restore even with the built-in helpful stuff), and privileged stuff like networking, USB, custom background services, and hardware support. There was too much undocumented magic tweaking necessary to make a physical laptop usable. ): Maybe it's improved?