[PATCH v5 3/7] qcow: Tolerate backing_fmt=, but warn on backing_fmt=raw

Eric Blake eblake at redhat.com
Mon Jun 22 21:58:15 UTC 2020

On 5/5/20 10:30 AM, Eric Blake wrote:
> On 5/5/20 2:35 AM, Kevin Wolf wrote:
>> Am 03.04.2020 um 19:58 hat Eric Blake geschrieben:
>>> qcow has no space in the metadata to store a backing format, and there
>>> are existing qcow images backed both by raw or by other formats
>>> (usually qcow) images, reliant on probing to tell the difference.
>>> While we don't recommend the creation of new qcow images (as qcow2 is
>>> hands-down better), we can at least insist that if the user does
>>> request a specific format without using -u, then it must be non-raw
>>> (as a raw backing file that gets inadvertently edited into some other
>>> format can form a security hole); if the user does not request a
>>> specific format or lies when using -u, then the status quo of probing
>>> for the backing format remains intact (although an upcoming patch will
>>> warn when omitting a format request).  Thus, when this series is
>>> complete, the only way to use a backing file for qcow without
>>> triggering a warning is when using -F if the backing file is non-raw
>>> to begin with.  Note that this is only for QemuOpts usage; there is no
>>> change to the QAPI to allow a format through -blockdev.
>>> Add a new iotest 290 just for qcow, to demonstrate the new warning.
>>> Signed-off-by: Eric Blake <eblake at redhat.com>
>> Somehow this feels backwards. Not specifying the backing file format at
>> all isn't any safer than explicitly specifying raw.
>> If there is a difference at all, I would say that explicitly specifying
>> raw means that the user is aware what they are doing. So we would have
>> more reason to warn against raw images if the backing format isn't
>> specified at all because then the user might not be aware that they are
>> using a backing file that probes as raw.
> Prior to this patch, -F does not work with qcow.  And even with this 
> patch, we still cannot store the explicit value of -F in the qcow file. 
> Anything that does not use -F must continue to work for now (although it 
> may now warn, and in fact must warn if we deprecate it), while anything 
> explicit is free to fail (since it failed already), but could also be 
> made to work (if letting it work is nicer than making it fail, and where 
> "work" may still include a warning, although it's pointless to have 
> something brand new that works but is deprecated out of the box).  So 
> the following is my summary of the two options we can choose between:
> Option 1, qcow backed by raw is more common than qcow backed by other, 
> so we want:
> raw <- qcow, no -F: work without warning (but if backing file is edited, 
> a future probe seeing non-raw would break image)
> raw <- qcow, with -F: work without warning (but if backing file is 
> edited, a future probe seeing non-raw would break image)
> other <- qcow, no -F: works but issues a warning (but backing file will 
> always probe correctly)
> other <- qcow, with -F: fails (we cannot honor the user's explicit 
> request, because we would still have to probe)
> Option 2, qcow backed by other is more common than qcow backed by raw, 
> so we want:
> raw <- qcow, no -F: works but issues a warning (using a raw backing file 
> without explicit buy-in is risky)
> raw <- qcow, with -F: works but issues a warning (explicit buy-in will 
> still require subsequent probing, and a backing file could change which 
> would break image)
> other <- qcow, no -F: works without warning
> other <- qcow, with -F: works without warning (later probing will still 
> see non-raw)
> It looks like you are leaning more towards option 1, while my patch 
> leaned more towards option 2.  Anyone else want to chime in with an 
> opinion on which is safer vs. easier?

> Option 3:
> completely deprecate qcow images with backing files, as there is no safe 
> way to do things favoring either raw (option 1) or non-raw (option 2), 
> and therefore accept -F solely for convenience with the rest of the 
> series, but always issue a warning regardless of whether -F was present.

Hearing no other opinion in the meantime, I've come up with option 4:

raw <- qcow, no -F: works but issues a warning to use -F (the user 
should be explicit that they know they are using raw)
raw <- qcow, with -F raw: a probe is attempted, if it returns anything 
other than raw, then fail (since we can't store the backing type, and 
the user's explicit type didn't match reality); otherwise works without 
warning (users tend to treat backing files as read-only, so even though 
editing a backing file could make it appear non-raw, that's less likely 
to happen)
other <- qcow, no -F: works without warning (we'll probe in future 
opens, but the probe will see the same file type and not corrupt user data)
other <- qcow, with -F: a probe is attempted and must match, but 
otherwise works without warning (we'll still have to probe in future 
opens, but it's no worse than before)

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

More information about the libvir-list mailing list