This bug's existence and its patch have already made some worried. From the Qubes OS developers: [1] Additional thoughts by Qubes Security Team ======

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/master/QSBs/qsb-018-2015.txt https://raw.githubusercontent.com/QubesOS/qubes-secpack/mast...