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 <ebl...@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. Kevin
