Xen hypervisor memory corruption due to x86 emulator flaw

Xen hypervisor memory corruption due to x86 emulator flaw
xenbits.xen.org

    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.

Things happen. We should be glad that these sort of security problems are being found and addressed; it would be naive to believe Xen or any other large codebase has zero security problems.

VM's should be regularly patched anyway, which usually requires a reboot now and then. If it were a physical server, the same would be true; just because things are in the "cloud" now doesn't mean they will have infinite uptime.

I understand that sometimes these services reboot and patch with little notice, but this should be built into any Terms Of Service constructed with your client(s); ie. "We will patch and reboot your service for critical vulnerabilities as quickly as possible, which in some circumstances may leave only short notice."