Hacker Neue

Preferences
rwmj parent
Some proprietary code replacing qemu (but still using KVM). Since they still have to emulate PC devices, this just means they have a different set of security holes and fewer people reviewing the code.
sitkack
Given QEMUs track record, I'd wager that the goog code gets more reviewers and more testing. QEMU is literally swiss cheese, or it emulates real swiss cheese, poorly.
bonzini
Any proof of what you are saying, or is it just FUD?

Most QEMU CVEs are related to devices that should never be used in cloud provider scenarios (you'll often find that they are disabled in RHEL for this exact reason). If anything, prompt handling of vulnerabilities in those devices is a sign of taking security seriously...

j_s
Not sure about OP; it is more of an appeal to authority here: https://www.hackerneue.com/item?id=13484146

No doubt in my mind Google has the top-tier working on this, at least now that GCE is public-facing. I was impressed to read they actively monitor/mitigate Rowhammer, something I've not seen mentioned anywhere else (could just be my ignorance).

peterwwillis
QEMU is a 14 year old codebase designed for research and cross-platform emulation. It is not developed with a focus toward ongoing security testing/auditing.

Xen uses a stripped-down QEMU to boot unpatched guest OSes. However, even Xen doesn't test its qemu-xen components extensively. Writing a new purpose-built emulator (assuming you know what you're doing) is a better idea.

edit: Or use PV guests, and skip all potential QEMU flaws.

rwmj OP
Sorry, this is completely wrong FUD. Paolo Bonzini and I work at Red Hat and there is constant review of the QEMU codebase, both for code quality and security issues. Furthermore devices in RHEL are whitelisted. TCG ("cross-platform emulation") is not involved at all when you're using KVM. A newly written emulator would just have a new set of vulnerabilities. When you don't know what you're talking about, please just don't.
peterwwillis
I'm glad to hear that! When did you implement fuzzing coverage? After the 2016 Qemu mailing list article I read where they're asking someone to look into applying to Google's oss fuzzing project? And how does your whitelisted set compare to Xen's stripped-down qemu support?
rwmj OP
I'm actually fuzzing qemu's block device layer as we speak.

From the latest run:

    │        run time : 11 days, 23 hrs, 12 min, 49 sec    │  cycles done : 0      │
    │   last new path : 0 days, 12 hrs, 55 min, 7 sec      │  total paths : 364    │
    │ last uniq crash : none seen yet                      │ uniq crashes : 0      │
    │  last uniq hang : 0 days, 4 hrs, 4 min, 36 sec       │   uniq hangs : 2      │
Re the comparison with Xen's qemu, you can grab the sources for RHEL's qemu-kvm and qemu-kvm-rhev packages and examine the driver whitelists, patches and ./configure line yourself.
bonzini
You forgot to mention that you could write it in Rust. :)

This item has no comments currently.