Qemu/KVM fuzzing - next steps

Qemu/KVM fuzzing - next steps

[Darren Kenny]

Hi,

I've been following Alexander's fuzzing changes from the GSoC
project, and it's looking like an excellent start on the
introduction of fuzzing into the world of Qemu/KVM.

I had a couple of off-list e-mails with Stefan and Alexander, to get
some idea of what the intent was going forward, and it was suggested
that we should discuss things in the open on the list to allow
everyone to contribute.

Unfortunately, I'm probably not going to be able to make it to the
KVMForum at the end of the month, so guess I'll have to settle for
e-mail for now :)

It is my understanding that the primary focus is to work on a
solution that would permit integration into Google's OSSFuzz
service[1] to allow for continuous fuzzing and automatic reporting
of issues found.

Once Alexander lands his patches, things will be 1 step closer to
this goal.

The question then is, well what next?

From what Stefan said to me, the intention is to work on expanding
the scope of the fuzzing, adding more test cases for a wider range
of machine and devices types.

I hope to be able to help out here, since this is an area that I'm
also interested in with my work in Oracle Linux's virtualization
team.

How would you like to move forward? Is there an ordered list of
device or machines that we'd like to focus on anywhere? If not,
could we create one?

Thanks,

Darren.

[1] - https://github.com/google/oss-fuzz

Re: Qemu/KVM fuzzing - next steps

[Peter Maydell]

On Thu, 3 Oct 2019 at 11:50, Darren Kenny <darren.kenny@oracle.com> wrote:
> How would you like to move forward? Is there an ordered list of
> device or machines that we'd like to focus on anywhere? If not,
> could we create one?

Roughly, "anything that can be used with KVM" is our
security boundary, so we should start with fuzzing the
devices and machines that can be used with it.
QEMU has a ton of implementations of device and machine
models that can only be used with TCG emulation, but we
don't make any promises about guest code not being able
to escape from a TCG-based machine, so we can leave those
until later (if at all).

thanks
-- PMM

Re: Qemu/KVM fuzzing - next steps

[Daniel P. Berrangé]

On Thu, Oct 03, 2019 at 11:58:23AM +0100, Peter Maydell wrote:
> On Thu, 3 Oct 2019 at 11:50, Darren Kenny <darren.kenny@oracle.com> wrote:
> > How would you like to move forward? Is there an ordered list of
> > device or machines that we'd like to focus on anywhere? If not,
> > could we create one?
> 
> Roughly, "anything that can be used with KVM" is our
> security boundary, so we should start with fuzzing the
> devices and machines that can be used with it.
> QEMU has a ton of implementations of device and machine
> models that can only be used with TCG emulation, but we
> don't make any promises about guest code not being able
> to escape from a TCG-based machine, so we can leave those
> until later (if at all).

Figuring out what can be used with KVM and what is only TCG is itself
not entirely easy.

One way to identify high priority devices would be to use 'virt-install'
to create some KVM guests and look at what devices it turns on for each
host architecture that is important. I'd probably prioritize x86_64
first, then any of ppc64/aarch64/s390x after, as that reflects where
much of the KVM userbase is likely spread.

Certainly anything virtio based is going to be top, but we do also use
some non-virtio stuff fairly often. eg various graphics cards in
particular, since virtio is quite new there &:

  https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/

vfio PCI passthrough is another common non-virtio device.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: Qemu/KVM fuzzing - next steps

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On Thu, Oct 03, 2019 at 11:49:28AM +0100, Darren Kenny wrote:
> How would you like to move forward? Is there an ordered list of
> device or machines that we'd like to focus on anywhere? If not,
> could we create one?

Feel free to claim a device (I recommend either a popular virtio device
or one of the on-board i440fx or q35 devices).

After Alexander's patches land I hope we can figure out Google oss-fuzz
integration so that QEMU has continuous fuzzing.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]