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 <ebl...@redhat.com>
Reviewed-by: Alberto Garcia <be...@igalia.com> Berto
