[PATCH v6 08/10] iotests: Specify explicit backing format where sensible

Kevin Wolf kwolf at redhat.com
Tue Jul 7 16:07:01 UTC 2020

Am 06.07.2020 um 22:39 hat Eric Blake geschrieben:
> There are many existing qcow2 images that specify a backing file but
> no format.  This has been the source of CVEs in the past, but has
> become more prominent of a problem now that libvirt has switched to
> -blockdev.  With older -drive, at least the probing was always done by
> qemu (so the only risk of a changed format between successive boots of
> a guest was if qemu was upgraded and probed differently).  But with
> newer -blockdev, libvirt must specify a format; if libvirt guesses raw
> where the image was formatted, this results in data corruption visible
> to the guest; conversely, if libvirt guesses qcow2 where qemu was
> using raw, this can result in potential security holes, so modern
> libvirt instead refuses to use images without explicit backing format.
> The change in libvirt to reject images without explicit backing format
> has pointed out that a number of tools have been far too reliant on
> probing in the past.  It's time to set a better example in our own
> iotests of properly setting this parameter.
> iotest calls to create, rebase, and convert are all impacted to some
> degree.  It's a bit annoying that we are inconsistent on command line
> - while all of those accept -o backing_file=...,backing_fmt=..., the
> shortcuts are different: create and rebase have -b and -F, while
> convert has -B but no -F.  (amend has no shortcuts, but the previous
> patch just deprecated the use of amend to change backing chains).
> Signed-off-by: Eric Blake <eblake at redhat.com>

This breaks at least 024 and 043 for qed because qemu-img info can't
print the backing file format there (qed only saves a flag whether it's
raw or non-raw).

We can fix the output filtering during the freeze, though.


More information about the libvir-list mailing list