[PATCH 9/9] WIP: Add tool for probing images

Peter Krempa pkrempa at redhat.com
Wed Feb 19 16:45:12 UTC 2020


On Wed, Feb 19, 2020 at 10:31:18 -0600, Eric Blake wrote:
> On 2/17/20 11:13 AM, Peter Krempa wrote:
> > Note that this is not finished yet, but allows to test the image
> > detection patches:
> 
> "allows to ${verb}" is not idiomatic; you want "allows ${verb}ing" or
> "allows $subject to ${verb}".  Here, I would go with "allows testing of the
> image detection patches".
> 
> > 
> > Prepare few images:
> 
> Prepare a few images:
> 
> > qemu-img create -f qcow2 /tmp/base.qcow2 10M
> > qemu-img create -f qcow2          -b /tmp/base.qcow2 /tmp/overlay1-noformat.qcow2
> > qemu-img create -f qcow2 -F qcow2 -b /tmp/base.qcow2 /tmp/overlay1-format.qcow2
> > qemu-img create -f qcow2 -F qcow2 -b /tmp/overlay1-format.qcow2 /tmp/overlay2-format.qcow2
> > qemu-img create -f qcow2          -b /tmp/overlay1-noformat.qcow2 /tmp/overlay2-noformat.qcow2
> > qemu-img creage -f qcow2 -b nbd://example/asdf /tmp/nbd-noformat.qcow2 10M
> > 
> 
> /tmp/overlay1-noformat.qcow2 is inherently unsafe.  The probe of
> /tmp/base.qcow2 returns qcow2, but we cannot trust whether that was because
> /tmp/base.qcow2 was actually qcow2 or if it was because /tmp/base.qcow2 was
> raw where the guest wrote a qcow2 header; in the former case our guess is
> correct, but in the latter case, even though we avoid a security issue of
> chasing further files under guest control, we do NOT avoid the issue of
> corrupting guest data (serving the qcow2 payload rather than the qcow2
> metadata that the guest wrote in a raw file is guest-visible data
> corruption).
> 
> > (Note that the last one prints error, but that's expected)
> > 
> > Probe images:
> > 
> > $ ./tests/qemublockprobe -f qcow2 -p /tmp/overlay1-noformat.qcow2
> > type: file (1)
> > path: /tmp/overlay1-noformat.qcow2
> > format: qcow2 (14)
> > protocol: none' (0)
> 
> Why the mismatched '?
> 
> > backing store raw: /tmp/base.qcow2
> > 
> > type: file (1)
> > path: /tmp/base.qcow2
> > format: qcow2 (14)
> > protocol: none' (0)
> > 
> > type: none (0)
> > path: (null)
> > format: none (0)
> > protocol: none' (0)
> > 
> 
> The tool needs to report that this image as potentially corrupt (our probe
> of qcow2 may be correct, or it may be a mistake for what was really raw, and
> without an explicit backing format, we are unwilling to hand the image to
> qemu for fear of data corruption visible to the guest, even if we have
> avoided a security hole of chasing files under guest control).

As noted previously, we've used these semantics forever. Prior to
introduction of blockdev, we probed the format, but assumed that the
image is 'raw' in such case. But we've never reported an error or done
anything. We started the VM and let qemu re-probe.

This meant that both 'raw' and 'qcow2' images without a backing file
were working without a hitch even with sVirt. Users not having the
benefit of sVirt were also possibly still seeing possible unwanted
access.

I'm specifically interrested in keeping both 'raw' and single layer
'qcow2' work as they did before because in my opinion it's not worse
than it was before when running qemu where libvirt wouldn't use blockdev
and _strictly_ better in case when we do use -blockdev, while not making
many users unhappy.

And there were already a lot of unhappy users.




More information about the libvir-list mailing list