Open dvyukov opened 6 years ago
More docs on virtio: http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-360006 And some particularly interesting parts: http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-90002 http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-1570001 http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-2020002
The ultimate goal for virtio fuzzing may be to make the fuzzer reach net/wifi/input stacks via connected virtio device, i.e. make the fuzzer pretend there is a new virtio net device connected, and then exchange some network packets via this device from both sides. See To Boldly Go Where No Fuzzer Has Gone Before: Finding Bugs in Linux’ Wireless Stacks through VirtIO Devices for an example.
There is a bunch of virtio drivers that use vring/virtqueue for host<->guest communication. These are used in lots of VM setups and represent host/guest security boundary. It would be useful to test guest communication with host virtio drivers over vring/virtqueue. syz_kvm_setup_cpu could pre-setup necessary things for VM (what?) and then ifuzz pseudo instructions do something sensible with regard to guest->host interface. Or maybe we could write some data to the vring that is normally written by the guest from the host as well? Here are some virtio docs: http://elixir.free-electrons.com/linux/v3.2/source/Documentation/virtual/virtio-spec.txt Also some useful entry points are vm_notify and vp_notify which are part of virtqueue signalling protocol.