[kyboren]

This bug's existence and its patch have already made some worried. From the Qubes OS developers: [1]

    Additional thoughts by Qubes Security Team
    ===========================================
    
    We see several problems that concern us about this vulnerability and
    patching process:
    
    1) It seems really difficult to understand why would anybody design a
    structure like the one shown above, which uses a union to store two,
    RADICALLY DIFFERENTLY TRUSTED data: an internal pointer into
    hypervisor memory and VM-provided UNTRUSTED DATA? Such design decision
    made by one of the core hypervisor developer is certainly worrying.
    We're not sure if it would be more worrying if this was done purposely
    vs by carelessness...
    
    2) We are not entirely convinced if the way Xen Security Team decided
    to address this vulnerability is really optimal, security wise. It
    seems like a more defensive approach would be to get rid of this
    dangerous construct of reusing the same memory for both an internal
    pointer and VM-provided data. Apparently Xen developers believe that
    they can fully understand the code, with all its execution paths, for
    decoding x86 operands. This optimistic attitude seems surprising,
    given the very bug we're discussing today.
    
    3) This lack of defensive programing and perhaps over confidence (in
    ability to fully understand all the code paths) has been demonstrated
    by the Xen Security Team also previously. In the recently released XSA
    109 [2], the official patch also seemed to address the problem much
    earlier in the execution path rather than at the actual offending
    instructions, i.e. those that performed the NULL-dereference. While
    asked specifically about adding at least an additional check on these
    instructions, the Xen developers were unwilling to implement it
    implying potential performance impact.
    
    4) This is all certainly a bit disconcerting and we hope we could
    start a bit more public debate on these issues, especially among
    independent security researchers. We still believe Xen is currently
    the most secure hypervisor available, mostly because of its unique
    architecture features, that are lacking in any other product we are
    aware of.

[1]: https://raw.githubusercontent.com/QubesOS/qubes-secpack/mast...

[zokier]

> We still believe Xen is currently the most secure hypervisor available, mostly because of its unique architecture features, that are lacking in any other product we are aware of.

Does anyone know why KVM would be considered less secure than Xen?

[detaro]

(from memory, there are some design docs for Qubes OS floating around that discuss this) Xen is relatively small and contained, KVM sits on top of a full Linux kernel and potentially can access all of it, making it harder to tell what is accessible/exploitable and what is not. KVM also uses Qemu running as a process on the host linux for interfacing the VM, again exposing more potential attack surface. And I think Xen is better at isolating drivers, which for Qubes OS is a fundamental principle.

[cthalupa]

>And I think Xen is better at isolating drivers

Xen allows for creating an entire stub domU solely for running the driver, then giving a running guest access via ring buffer in a shared memory segment.

(So, yep, you're correct in your thinking)

[rwmj]

My guess would be a couple of things: small Xen hypervisor vs potentially large Linux kernel, and driver domains. The latter involves putting each driver into its own domain (ie. Xen VM or process equivalent) and it means that bad drivers can do less damage to the rest of the system.

[zokier]

Sounds like Tanenbaum vs Torvalds redux..

[weland]

de Raadt's remarks about virtualization do spring up in my mind.