Re: discard and v2 qcow2 images

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Mar 20, 2020 at 02:35:44PM -0500, Eric Blake wrote:
> On 3/20/20 1:58 PM, Alberto Garcia wrote:
> > Hi,
> > 
> > when full_discard is false in discard_in_l2_slice() then the selected
> > cluster should be deallocated and it should read back as zeroes. This
> > is done by clearing the cluster offset field and setting OFLAG_ZERO in
> > the L2 entry.
> > 
> > This flag is however only supported when qcow_version >= 3. In older
> > images the cluster is simply deallocated, exposing any possible
> > previous data from the backing file.
> 
> Discard is advisory, and has no requirements that discarded data read back
> as zero.  However, if write zeroes uses discard under the hood, then THAT
> usage must guarantee reading back as zero.
> 
> > 
> > This can be trivially reproduced like this:
> > 
> >     qemu-img create -f qcow2 backing.img 64k
> >     qemu-io -c 'write -P 0xff 0 64k' backing.img
> >     qemu-img create -f qcow2 -o compat=0.10 -b backing.img top.img
> >     qemu-io -c 'write -P 0x01 0 64k' top.img
> > 
> > After this, top.img is filled with 0x01. Now we issue a discard
> > command:
> > 
> >     qemu-io -c 'discard 0 64k' top.img
> > 
> > top.img should now read as zeroes, but instead you get the data from
> > the backing file (0xff). If top.img was created with compat=1.1
> > instead (the default) then it would read as zeroes after the discard.
> 
> I'd argue that this is undesirable behavior, but not a bug.

I think the ability to read old data from the backing file could
potentially be considered a security flaw, depending on what the
original data was in the backing file.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|