Am 03.04.2020 um 19:58 hat Eric Blake geschrieben:
Creating an image that requires format probing of the backing image
is
inherently unsafe (we've had several CVEs over the years based on
probes leaking information to the guest on a subsequent boot, although
these days tools like libvirt are aware of the issue enough to prevent
the worst effects). However, if our probing algorithm ever changes,
or if other tools like libvirt determine a different probe result than
we do, then subsequent use of that backing file under a different
format will present corrupted data to the guest. Start a deprecation
clock so that future qemu-img can refuse to create unsafe backing
chains that would rely on probing. Most warnings are intentionally
emitted from bdrv_img_create() in the block layer, but qemu-img
convert uses bdrv_create() which cannot emit its own warning without
causing spurious warnings on other code paths. In the end, all
command-line image creation or backing file rewriting now performs a
check.
However, there is one time where probing is safe: if we probe raw,
then it is safe to record that implicitly in the image (but we still
warn, as it's better to teach the user to supply -F always than to
make them guess when it is safe).
You're not stating it explicitly, but I guess the thing that you mean
that is actually unsafe is if you have a raw image, always pass
format=raw to QEMU (so the guest could write e.g. a qcow2 header), but
then create a backing file without -F, so it will be probed. This is as
bad as specifying format=raw only sometimes.
I don't like the idea of responding to this by making raw images more
convenient to use than actual image formats.
How about we approach it the other way around: The troublemaker is raw,
so let's require specifying raw explicitly, and record the probed format
implicitly in other cases. This is a bit weaker in the immediate effect
in that it doesn't protect you when you actually deal with a malicious
image, but in normal use it will point out where your scripts or
management software is too careless. The final result should be that
management tools are fixed and you'll be safe, while manual users who
can usually trust their guests aren't inconvenienced too much.
Kevin