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

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

[Kevin Wolf]

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.

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.

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?

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

Kevin

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

[Daniel P. Berrangé]

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