Grsecurity and Virtualization

[two2tango]

Hi Spender. In light of VENOM and your interesting comments on the limits of QEMU sandboxing I wanted to ask a few questions.

1) What is the most secure opensource hypervisor to use today? Its a loaded question so let me break it down further and explain. Isn't the KVM approach to moving as much emulation as possible into QEMU userspace preferable to the Xen pure PV approach of having device backends in the privileged VMM kernel? The reasoning is that at least with QEMU, exploit mitigation measures in userspace can make things harder even if a hole is found, while an exploit in Xen's VMM kernel with its many baked-in emulators ends the game?

http://www.gossamer-threads.com/lists/x ... 492#347492
http://xenbits.xen.org/xsa/advisory-105.html

CVE numbers suggest that Xen is no panacea when compared to QEMU-KVM.

http://www.cvedetails.com/vendor/6276/XEN.html
http://www.cvedetails.com/product/19922 ... ndor_id=25
http://www.cvedetails.com/vendor/7506/Qemu.html


2) Can Grsecurity on the host be used to harden QEMU-KVM and prevent any successful exploitation of the BO that is VENOM? This comment on the KVM mailing list suggests that KVM's design can't benefit from Grsecurity's protection.

3) If QEMU is successfully exploited, will Grsecurity be able to limit the resources available to an attacker compared to the lacking seccomp sandbox you mention? How much harder will it be to take over the host?

4) What is a foolproof security design to make virtualization safe in your opinion and is it something Grsecurity can do or have added?



Off-topic but will mainlining of your patches ever happen?

[PaX Team]

in general, code in userland can be better protected than code in privileged mode (be that a ring-0 kernel or a hypervisor) because in the latter case we also have to take care of self-protection which is quite hard (and an unfinished business so far). since qemu is a userland process, all the usual protections apply to it (save for MPROTECT since it can generate code at runtime). as for kvm vs. xen/dom0, kvm works fine with our protection mechanisms (the bug you linked to was resolved long ago already). xen could also make use of the security features we have for the kernel but that'd be a non-trivial porting effort so it's not happened yet. as for mainlining, it's not likely to happen ever for reasons that we discussed many times over now .

[csirac2]

1) What is the most secure opensource hypervisor to use today? Its a loaded question so let me break it down further and explain. Isn't the KVM approach to moving as much emulation as possible into QEMU userspace preferable to the Xen pure PV approach of having device backends in the privileged VMM kernel? The reasoning is that at least with QEMU, exploit mitigation measures in userspace can make things harder even if a hole is found, while an exploit in Xen's VMM kernel with its many baked-in emulators ends the game?

Is it possible you are mistaken on pure PV approach of having device backends in the privileged VMM kernel? Device pass-through has been a feature of Xen since at least Xen 3.0 (circa 2005), which is older than KVM itself

I've agonized in the past about whether PV is more secure than HVM or not. On balance I decided that avoiding any trace of QEMU at all, i.e. just running Xen with pure PV guests has to be safer than leaning on QEMU for anything, even when running QEMU as a normal user in a stub domain.

Of course, it's best to have no network or other exposed device drivers running the physical hardware from dom0, which is why it's saner to pass those devices on to a domU instead.

I'm actually not sure you'll find many professional deployments of Xen where you have QEMU processes running in dom0, but perhaps I'm just showing my ignorance...

At the end of the day, QEMU was a remarkable thing for its day and proved that high-performance emulation is possible. Nowadays I think the fact that security isolation was not originally one of the primary design goals for QEMU is really showing through.