4 ms·

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. X

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 10y ago
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 10y ago
  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 10y ago
    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 10y ago
You forgot to mention that you could write it in Rust. :)

rwmj 10y ago

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 10y ago
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 10y ago
  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 10y ago

You forgot to mention that you could write it in Rust. :)