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 :|
