secur101

Thanks for your reply. I made some suggestions for KVM and QEMU below. Also I was wondering what your POV is on my thoughts:

https://news.ycombinator.com/item?id=14227605 https://news.ycombinator.com/item?id=14228563

I'm still rooting for KVM because it has the best hardware compatibility, it in mainline and its performance is the best. However the security situation with QEMU is not as rosy as some of you portray it (and its not as bad as it looks either). The average customer/user is going to look at the number of QEMU CVEs on cvedetails and compare them to the number of Xen's and go with the latter. However most of the QEMU bugs only affect legacy emulated hardware or components not enabled in a KVM guest, most won't think that far.

It would clear things up if you have a table on your site showing which QEMU vulnerabilties affect a specified default configuration of a RHEL/Debian guest out of the box in libvirt. See this for example: https://www.qubes-os.org/security/xsa/

What I want to see:

* Adoption of QEMU-lite as the default mode for Linux guests. There's no point to running Linux in almost any emulated hardware.

* A builtin monitoring solution like Google has that detects excessive DRAM bitflips [1] and cache misses [2] and terminates the guests to foil rowhammer and covert channel attacks.

* A re-design of KSM thats not prone to rowhammer abuse [3]

*

[1] https://cloudplatform.googleblog.com/2017/01/7-ways-we-harde...

[2] https://www.usenix.org/system/files/conference/usenixsecurit...

[3] http://www.cs.vu.nl/~kaveh/pubs/pdf/ffs-usenixsec16.pdf

My logic is:

Without a hardened kernel, LSM can be trivially bypassed and seccomp seems to whitelist everything under the sun. This only leaves us with QEMU code quality to rely on. Since Grsec is not longer available this becomes even more urgent.

Xen relies on stubdoms to isolate QEMU from their TCB which leaves them with bugs in the hypervisor itself as the only avenue of attack. The number of Xen-only bugs vs Linux is way fewer. Please correct me if I'm wrong.

@bonzini I use virtio-9p for shared folders all the time why did you dismiss that as a non-issue: https://news.ycombinator.com/item?id=13755021

If you are a KVM dev please look seriously into using an advanced, intelligent fuzzer like the DARPA Grand Challenge winner Shellphish. It can find security bugs and propose patches for them:

https://github.com/shellphish http://angr.io/

*

Security aside I find Libvirt more wanting in UX. The single biggest roadblock is the lack of a virtual appliance implementation that new comers can point and import to from Virt-Manager. I hope this gets resolved down the line.

@rwmj can you please point to the list of white-listed QEMU-KVM devices used in RHEL?