Re: [RFC] virtio-villain: Guest fault injection for VMM robustness

[Matias Ezequiel Vara Larsen <mvaralar@redhat.com>]

On Sat, Jul 04, 2026 at 03:37:21PM +0200, Anatol Belski wrote:
> Hi,
> 
> I would like to share virtio-villain, a guest side fault injection
> harness for virtio device models. The repository is at
> https://github.com/weltling/virtio-villain
> 
> Comments on the approach, the coverage so far, and test cases worth
> adding are all welcome. While the tool targets multiple hypervisors,
> QEMU support is active and has already surfaced a few initial bugs.
> 
> Threat model. The harness operates under the hostile guest model. A
> malicious or buggy guest driver violates the virtio protocol on
> purpose. It targets the modern 1.2+ interface only. The test binary
> runs as init inside a minimal initramfs, bypasses the kernel virtio
> drivers with initcall_blacklist, walks the PCI capability list
> itself, programs the queues by hand, and asserts on the exact spec
> mandated values. Each test violates one driver MUST rule and checks
> that the host VMM process handles it gracefully without crashing,
> wedging, or corrupting state.
> 
> Scope and status. The primary target so far is Cloud Hypervisor,
> which accounts for most of the findings to date. Testing focuses on
> the amd64 and aarch64 architectures. QEMU is supported as a PCI host
> and as the microvm MMIO host. Differential testing across VMMs,
> running the same suite and comparing outcomes, is the roadmap. This
> is a spec violation fault injection tool that surfaces unvalidated
> input handling rather than an exploit framework, so no CVEs have
> been issued.
> 
Thanks for sharing it. I am also interesting on finding violations of
the virtio specification. I presented something two years ago in LPC
(see https://lpc.events/event/18/contributions/1897/). As a result of
that work, we worked adding kani proofs in rust-vmm devices. The
validation of the spec is coded in RUST and by using kani we verify that
the implemented devices follows the specification. For some
requirements, we were able to prove that the device is conform. The
proofs are written together with the implementation of the device like
tests.  

> What is already covered. There are two transports, modern virtio PCI
> and virtio MMIO via the QEMU microvm machine type. A dozen device
> categories are present. They include net, block with zoned support,
> console, entropy, balloon, vsock, virtio-fs, IOMMU, virtio-mem,
> virtio-pmem, RTC, and watchdog, plus the admin queue and the split
> and packed virtqueue layers. Test cases derive from the virtio spec
> normative text, each tied to a specific section.
> 
> Beyond the static suite there are two extra layers.
> 
>   - Host coordinated sidecars. A test can ship a small Python file
>     that drives the host, for example pause, snapshot, hot plug, or
>     config change, while the guest makes a precise assertion the
>     kernel driver cannot make. As an example, snapshot the VM while
>     the guest sits between two block reads, then assert the used
>     ring drains deterministically on resume.
> 
>   - A coverage guided mutation fuzzer. It encodes a descriptor chain
>     into a 4096 byte blob, patches it into a fuzz guest, boots the
>     VMM, and classifies the result. With a coverage instrumented
>     build it feeds new edges back into the corpus. Crashes are
>     grouped by error class for triage.
> 
> Impact. Many findings have led to substantial improvements in
> virtio spec compliance and stability in Cloud Hypervisor, from

Feel free to file patches to the virtio specification in cases you think
the spec is too permissive. 

> input validation gaps to a config read that could take down a VM
> on aarch64. In QEMU the harness has surfaced a few guest triggered

At some point, I wanted to add some checks in QEMU to inform user when
guest violates the spec. That would help to catch some issues with less
testing. For example, two years ago the virtio-sound driver was silently
violating the spec by writing the content of the buffers that were
already in the available ring. 

> hangs and a double completion. The repository README lists the
> details with PR links and the test ID for each.
> 
> Thanks for reading.
> 
> Anatol Belski
>