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.
It's so difficult to impress upon some people just important documentation is. And when they do it, they half-ass it by copying stuff from source code and not adding any context.
That said, I'm not sure for which kind of use cases it would be useful to run it this way, as the performance won't be amazing. I find TCG acceleration mainly useful for debugging and foreign systems emulation.
That's an interesting and I would argue, contrarian take?
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."
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), specifically the 'hvt' tender.
"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/kvmfor...
> - 3 were not related to the C language
wow
> - 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.
And then there are countless GitHub projects where the README.md file, which is usually first thing I read, that is super well documented and written for the noob (imo). The best example of that so far, especially for someone like me just getting started with the framework, is the gin Golang http framework: (https://github.com/gin-gonic/gin) -- that readme is full of useful examples.