Re: [PATCH 05/17] block: Don't advertise zero_init_truncate with encryption

[Alberto Garcia]

On Fri 31 Jan 2020 06:44:24 PM CET, Eric Blake wrote:
> Commit 38841dcd correctly argued that having qcow2 blindly return 1
> for .bdrv_has_zero_init() is wrong for preallocated images built on
> block devices, while .bdrv_has_zero_init_truncate() can still return 1
> because it is only relied on when changing size with PREALLOC_MODE_OFF
> (and this is true even for v2 images which lack the notion of an
> explicit zero cluster, since the block layer already filters out the
> case of a larger backing file leaking through).  However, it missed
> the fact that encrypted images do not default to reading as zero in
> any case.
>
> However, instead of changing qcow2's .bdrv_has_zero_init_truncate() to
> point to a one-off function that special-cases bs->encryption, it is
> smarter to just move the logic about encryption directly to the block
> layer (that is, the driver callbacks will never be invoked for
> encrypted images, just like they are already not called when a backing
> file is present).  This solution fixes the qcow2 issue, has no effect
> on the crypto driver (which already lacks .bdrv_has_zero_init*
> callbacks), and no other driver currently uses bs->encrypted.
>
> One other reason to fix this at the block layer: any information we
> expose about an encrypted image that in turn may alter timing of
> algorithms run on that image can be considered a (slight) information
> leak; refusing to optimize zero handling of encrypted images thus
> avoids the possibility of that being a security concern.
>
> Signed-off-by: Eric Blake <address@hidden>

Reviewed-by: Alberto Garcia <address@hidden>

Berto