3 ms·

From the guest perspective, the differences are minimal. Even boot time of the guest (thinking about a custom-built minimalist Linux kernel here) is roughly the

by slpnix 7y ago

From the guest perspective, the differences are minimal. Even boot time of the guest (thinking about a custom-built minimalist Linux kernel here) is roughly the same. On the host side, things are more interesting. Firecraker has a smaller TCB (Trusted Computing Base), is written in Rust, and is statically linked. On the other hand, QEMU provides more features (especially in the block layer, with more formats, network-based block devices, asynchronous I/O...), can be configured at build time to adapt it to a particular use case, and has a pretty good security record. In the end, KVM userspace VMMs (Virtual Machine Monitors) are learning from each other, giving users more options to choose from. Everybody wins.

rrdharan 7y ago
> QEMU... has a pretty good security record That's an interesting and I would argue, contrarian take? https://www.theregister.co.uk/2017/01/30/google_cloud_kicked_qemu_to_the_kerb_to_harden_kvm/ https://www.theregister.co.uk/2017/01/30/google_cloud_kicked... "QEMU has a long track record of security bugs, such as VENOM, and it's unclear what vulnerabilities may still be lurking in the code."
- slpnix 7y ago
  I think the slide 14 from the talk "Reports of my Bloat Have Been Greatly Exaggerated" [1] presented by Paolo Bonzini at KVM Forum 2019 gives some good perspective about QEMU's security track: "Of the top 100 vulnerabilities reported for QEMU: - 65 were not guest exploitable - 3 were not in QEMU :) - 5 did not affect x86 KVM guests - 3 were not related to the C language - Only 6 affected devices normally used for IaaS The most recent of these 6 was reported in 2016" The rest of this talk was also very interesting. I encourage everyone with 10 minutes to spare and an interest in VMMs to take a look at the slides. [1] https://static.sched.com/hosted_files/kvmforum2019/c6/kvmforum19-bloat.pdf https://static.sched.com/hosted_files/kvmforum2019/c6/kvmfor...
  - ketralnis 7y ago
    > "Of the top 100 vulnerabilities reported for QEMU: > - 3 were not related to the C language wow
  - mato 7y ago
    > "Of the top 100 vulnerabilities reported for QEMU: > - 65 were not guest exploitable > [...] Which leaves about 30 that presumably were guest exploitable. Don't get me wrong -- QEMU is useful. As a "kitchen sink" solution that runs anything, anywhere, with any useful combination of emulated {devices,processors,systems}. However, this is also its biggest weakness. Which is why Google and Amazon all run their own custom VMMs for their IaaS services. The microvm machine type as described here is a great step to improve this situation. The next step in my book would be to reconfigure QEMU's build system to allow building a binary that only supports the devices provided by microvm, and nothing else.
mato 7y ago
> In the end, KVM userspace VMMs (Virtual Machine Monitors) are learning from each other, giving users more options to choose from. Everybody wins. Indeed. Nice to see that the cross-pollination is happening. For folks interested in what can be accomplished with userspace VMMs, a very minimalist example is the Solo5 project (https://github.com/Solo5/solo5 https://github.com/Solo5/solo5), specifically the 'hvt' tender.

by slpnix 7y ago

rrdharan 7y ago

> QEMU... has a pretty good security record That's an interesting and I would argue, contrarian take? https://www.theregister.co.uk/2017/01/30/google_cloud_kicked_qemu_to_the_kerb_to_harden_kvm/ https://www.theregister.co.uk/2017/01/30/google_cloud_kicked... "QEMU has a long track record of security bugs, such as VENOM, and it's unclear what vulnerabilities may still be lurking in the code."

slpnix 7y ago
I think the slide 14 from the talk "Reports of my Bloat Have Been Greatly Exaggerated" [1] presented by Paolo Bonzini at KVM Forum 2019 gives some good perspective about QEMU's security track: "Of the top 100 vulnerabilities reported for QEMU: - 65 were not guest exploitable - 3 were not in QEMU :) - 5 did not affect x86 KVM guests - 3 were not related to the C language - Only 6 affected devices normally used for IaaS The most recent of these 6 was reported in 2016" The rest of this talk was also very interesting. I encourage everyone with 10 minutes to spare and an interest in VMMs to take a look at the slides. [1] https://static.sched.com/hosted_files/kvmforum2019/c6/kvmforum19-bloat.pdf https://static.sched.com/hosted_files/kvmforum2019/c6/kvmfor...
- ketralnis 7y ago
  > "Of the top 100 vulnerabilities reported for QEMU: > - 3 were not related to the C language wow
- mato 7y ago
  > "Of the top 100 vulnerabilities reported for QEMU: > - 65 were not guest exploitable > [...] Which leaves about 30 that presumably were guest exploitable. Don't get me wrong -- QEMU is useful. As a "kitchen sink" solution that runs anything, anywhere, with any useful combination of emulated {devices,processors,systems}. However, this is also its biggest weakness. Which is why Google and Amazon all run their own custom VMMs for their IaaS services. The microvm machine type as described here is a great step to improve this situation. The next step in my book would be to reconfigure QEMU's build system to allow building a binary that only supports the devices provided by microvm, and nothing else.

mato 7y ago

> In the end, KVM userspace VMMs (Virtual Machine Monitors) are learning from each other, giving users more options to choose from. Everybody wins. Indeed. Nice to see that the cross-pollination is happening. For folks interested in what can be accomplished with userspace VMMs, a very minimalist example is the Solo5 project (https://github.com/Solo5/solo5 https://github.com/Solo5/solo5), specifically the 'hvt' tender.