Re: [PATCH v3] qcow2: Forbid discard in qcow2 v2 images with backing files

[Eric Blake]

On 3/27/20 11:48 AM, Alberto Garcia wrote:
> A discard request deallocates the selected clusters so they read back
> as zeroes. This is done by clearing the cluster offset field and
> setting QCOW_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 stale
> data from the backing file.
>
> Since discard is an advisory operation it's safer to simply forbid it
> in this scenario.
>
> Note that we are adding this check to qcow2_co_pdiscard() and not to
> qcow2_cluster_discard() or discard_in_l2_slice() because the last
> two are also used by qcow2_snapshot_create() to discard the clusters
> used by the VM state. In this case there's no risk of exposing stale
> data to the guest and we really want that the clusters are always
> discarded.
>
> Signed-off-by: Alberto Garcia <address@hidden>
> ---

> +++ b/block/qcow2.c
> @@ -3784,6 +3784,12 @@ static coroutine_fn int 
> qcow2_co_pdiscard(BlockDriverState *bs,
>       int ret;
>       BDRVQcow2State *s = bs->opaque;
>   
> +    /* If the image does not support QCOW_OFLAG_ZERO then discarding
> +     * clusters could expose stale data from the backing file. */
> +    if (s->qcow_version < 3 && bs->backing) {
> +        return -ENOTSUP;
> +    }
> +

Hmm. Should we blindly always fail for v2, or can we be a little bit 
smarter and still discard a cluster in the top layer if the backing 
layer does not also have it allocated?  In other words, is it also worth 
checking bdrv_is_allocated(), and avoiding the -ENOTSUP failure in the 
case where the backing chain does not have any allocation of the same 
range (at which point, discarding the cluster in the top layer will read 
as zeroes rather than as stale data)?

But that's a minor optimization for an older file format; it's just as 
easy to tell users that if they want maximum discarding power on their 
active layer, then they should be using v3 images.

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