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