Re: [PATCH v3 1/4] block: Add trivial backing_fmt support to qcow, sheepdog, vmdk

[Eric Blake]

On 3/9/20 10:36 AM, Daniel P. Berrangé wrote:
> On Mon, Mar 09, 2020 at 04:21:12PM +0100, Kevin Wolf wrote:
> > Am 06.03.2020 um 23:51 hat Eric Blake geschrieben:
> > > For qcow2 and qed, we want to encourage the use of -F always, as these
> > > formats can suffer from data corruption or security holes if backing
> > > format is probed.  But for other formats, the backing format cannot be
> > > recorded.  Making the user decide on a per-format basis whether to
> > > supply a backing format string is awkward, better is to just blindly
> > > accept a backing format argument even if it is ignored by the
> > > contraints of the format at hand.
> > >
> > > Signed-off-by: Eric Blake <address@hidden>
> >
> > I'm not sure if I agree with this reasoning. Accepting and silently
> > ignoring -F could give users a false sense of security. If I specify a
> > -F raw and QEMU later probes qcow2, that would be very surprising.
>
> And if the user specifies "-F raw" and we probe qcow2, and the user
> does not realize this, they can become silently reliant on always
> probing qcow2. If we then honour the "-F raw" option in a later
> QEMU release, we'll break the behaviour they've relied on.
>
> IMHO, we must not accept "-F fmt" unless we're in a position to
> honour it.

So I'm thinking:

qemu-img create -f qcow -b backing.qcow -F qcow img.qcow   => okay

qemu-img create -f qcow -b backing.raw -F raw img.qcow   => okay, 
slightly risky (if backing.raw is ever changed to be non-raw), but then 
again, backing files tend to be read-only (do we even support commit on 
qcow images, or do we limit that to qcow2?)

qemu-img create -f qcow -b backing.qcow -F raw img.qcow   => fails, due 
to mismatch

qemu-img create -u -f qcow -b anything -F anything img.qcow $size  => 
fails: we can't write -F into the image, nor can we open anything to 
probe its type to check that -F was correct

qemu-img create -f qcow -b backing.qcow img.qcow   => warns, but okay 
(we did not get -F, but the probe works out)

qemu-img create -f qcow -b backing.raw img.qcow    => likewise warns

qemu-img create -f qcow -b backing.qcow2 img.qcow   => error; new qcow 
images (which you should avoid where possible anyways) must be backed by 
only raw or qcow, going forward

Other scenarios?  Do the above ideas look reasonable?

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