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.