QEMU includes the QEMU Storage Daemon. This provides more features than Cloud Hypervisor’s own block layer. It also includes a vhost-user server, which allows Cloud Hypervisor to delegate block operations to it.

QEMU Storage Daemon is written in C, but as it only performs block I/O it should be possible to isolate it in an extremely tight sandbox. Furthermore, a vulnerability in QEMU’s block code itself (as opposed to the daemon) would make enough of a splash that it isn’t going to go unnoticed. The daemon is (presumably) a thin wrapper over this code. QEMU’s block code is even secure against malicious qcow2 images, so long as backing files are not in use or the backing file name is not attacker-controlled. OpenStack relies on this.

While a native and efficient raw backend is definitely worthwhile, the value add of supporting non-raw images natively is less obvious. Non-raw images add a lot of complexity. As the reference implementation of qcow2, QEMU supports more features (such as encryption) and has additional runtime checks to prevent corruption.

Even if the risk of QEMU Storage Daemon is too high, another option would be to create a vhost-user-blk server under the rust-vmm organization. This could be used by multiple VMMs, including Cloud Hypervisor, Firecracker, and even QEMU.

Furthermore, @rbradford has recommended moving the qcow2 code out of process. Using vhost-user accomplishes this goal automatically.