TL;DR: If you can force emulation of the LGDT or LIDT instructions, you can replace the global memory segment descriptor table or interrupt descriptor table (resp.), since the instruction emulation code fails to check permissions properly.
It's worth nothing that very few people run HVM guests on xen if they can avoid it. The performance hit is considerable. Most xen setups I have seen are PV guests with pygrub bootloader. Host is debian amd64, guests are also debian amd64 or some variety of centos amd64.
Using paravirtualized devices is best practice, but a combination of PV and HVM ends up being faster for many operations - see http://www.brendangregg.com/blog/2014-05-07/what-color-is-yo... . Unfortunately HVM mode brings along QEMU which is a relatively large amount of code, though the bugs in QEMU have tended to be lower impact than bugs in the hypervisor itself.
While the risk from QEMU can largely be mitigated by running QEMU in a device model stub domain, a new mode called PVH (currently being rewritten) should theoretically be best in terms of performance, resource usage, and attack surface. See http://wiki.xen.org/wiki/Xen_Project_Software_Overview#PVH
pygrub runs in the context of the dom0 and should not be used with untrusted guests. Both grub legacy and grub2 work with PV mode now and there is no need for pygrub.
4 comments
[ 0.19 ms ] story [ 12.1 ms ] threadIt looks like he'll do one of those next, though. The last paragraph in TFA:
> A future blog post will talk about a guest-to-host escape, with a working exploit. Stay tuned!
While the risk from QEMU can largely be mitigated by running QEMU in a device model stub domain, a new mode called PVH (currently being rewritten) should theoretically be best in terms of performance, resource usage, and attack surface. See http://wiki.xen.org/wiki/Xen_Project_Software_Overview#PVH
pygrub runs in the context of the dom0 and should not be used with untrusted guests. Both grub legacy and grub2 work with PV mode now and there is no need for pygrub.