Re: [PATCH 9/9] WIP: Add tool for probing images
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).
$ ./tests/qemublockprobe -f qcow2 -p /tmp/overlay2-format.qcow2
type: file (1)
path: /tmp/overlay2-format.qcow2
format: qcow2 (14)
protocol: none' (0)
backing store raw: /tmp/overlay1-format.qcow2
type: file (1)
path: /tmp/overlay1-format.qcow2
format: qcow2 (14)
protocol: none' (0)
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)
This image is safe.
$ ./tests/qemublockprobe -f qcow2 -p /tmp/overlay2-noformat.qcow2
/home/pipo/build/libvirt/gcc/tests/.libs/lt-qemublockprobe: libvirt error: Requested
operation is not valid: format of backing image '/tmp/overlay1-noformat.qcow2' of
image '/tmp/overlay2-noformat.qcow2' was not specified in the image metadata (See
https://libvirt.org/kbase/backing_chains.html for troubleshooting)
This image is correctly identified as unsafe.
$ ./tests/qemublockprobe -f qcow2 -p /tmp/nbd-noformat.qcow2
/home/pipo/build/libvirt/gcc/tests/.libs/lt-qemublockprobe: libvirt error: Requested
operation is not valid: format of backing image 'nbd://example/asdf' of image
'/tmp/nbd-noformat.qcow2' was not specified in the image metadata (See
https://libvirt.org/kbase/backing_chains.html for troubleshooting)
This image is correctly identified as potentially unsafe because we were
unable to probe nbd://example/asdf (had the probe been successful, AND
returned a result of raw, then this image would be safe; had the probe
been successful but returned anything other than raw, it is no different
than the existing failure of the probe being unsuccessful)
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org