Re: [Qemu-devel] luks: Initial content of unwritten blocks

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

On Tue, Mar 20, 2018 at 04:04:21PM +0100, Kevin Wolf wrote:
> Hi,
> 
> I just tried to add luks support to qemu-iotests 025, a basic resize
> test, which made me realise that luks doesn't read zeros in unwritten
> blocks (which makes the test fail).
> 
> The reason for this is that we get zeros on the protocol layer (i.e. in
> the encrpyted data as it is on the disk), but not in the decrpyted
> format layer.

That is basically the same that you would see with dm-crypt luks impl
over a physical device. ie if /dev/sda1 is filled with zeros (or sparse
such that reading from unallocated sectors returns zeros), and you then
format it with luks, and then read data you'll not get zeros - you'll
get the decrypted zeros which is essentially random garbage. The user
would have to make a concious decision to fill the disk with all zeros
in the cipher text if they want their newly formatted luks voilume
to return all zeros.

> Now I'm wondering if that's a problem. Not reading zeros in the guest is
> unusual, but not unheard of (e.g. host_device), but visible zeros in the
> image file could be considered an information leak. On the other hand,
> qcow2 metadata for encrypted images is visible, too, so that's really
> just the same thing.

Leaking information to the guest on whether a sector in a qcow2 file is
allocated or unallocated, might be considered undesirable, but I think
that's one of the tradeoffs of using qcow2 in general not just when
luks is enabled in qcow.

> What do you think, is the current behaviour good enough or should we
> essentially enforce full preallocation for luks images and initialise
> the image so that zeros are visible on the format layer, but random
> encrypted stuff on the protocol layer?

I don't think that's neccessary, as long as users have the option to
opt-in to do that, which they do.

The more important missing piece of the puzzle currently is secure
delete. We need to provide a 'qemu-img rm' command for deleting
volumes that would explicitly overwrite the LUKS headers and key
material, rather than having apps just run plain 'rm'.

> Either way, we should probably document the decision somewhere as
> intentional.

Agreed.


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