zlacker

>>ploggi+(OP)
Their weakest point is the hypervisor, Xen, which while a better choice than Linux/KVM, is still extremely bloated and has a poor security history.

Thankfully, better designs such as seL4's VMM do exist, although it might need a little more work [1] until usable for the purpose.

[1] https://sel4.systems/Info/Roadmap/

>>snvzz+D3
Xen's hypervisor's size is very small. Qubes is about security and trustability of the whole system. In operating systems for measuring the trustability of the system, one very important measure is the lines of the code. Xen has a smaller footprint in the hypervisor part. Additionally, Xen has a robust model isolation for the drivers. That's why they went for Xen not KVM. But boy I wish to see more seL4. It was sad to see Gnu Hurd/seL4 didn't make it.

>>mmreza+d5
Qubes mailing list thread about hypervisor choices:

https://groups.google.com/forum/m/#!topic/qubes-devel/jEe4pQ...

> It seems one major residing problem with KVM is the Linux kernel (which is large and vulnerable). A port of KVM to a thinner base layer would obviate those issues.

>>walter+T9
One of the trends I told Joanna about (i.e secure L4 kernels) led to folks developing exactly that. It was called KVM-L4. Here you go.

http://os.inf.tu-dresden.de/papers_ps/liebergeld-diplom.pdf

Complexity was still yoo high. Most in high-assurance security were trying stuff like Nova microhypervisor as a result. KVM on separation kernels might be worth further investigation for these platforms that will stay on KVM regardless.