Re: [Qemu-devel] [PATCH v2 10/17] block: add generic full disk encryption driver

From: "Daniel P. Berrange" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 10/17] block: add generic full disk encryption driver
Date: Tue, 9 Feb 2016 09:55:03 +0000	[thread overview]
Message-ID: <20160209095503.GA24614@redhat.com> (raw)
In-Reply-To: <56B8F940.4020503@redhat.com>

On Mon, Feb 08, 2016 at 01:23:28PM -0700, Eric Blake wrote:
> On 02/08/2016 09:28 AM, Daniel P. Berrange wrote:
> 
> >> My vote: do the same as we do for qcow2 or any other format.  Make the
> >> size requested by the user as the size visible to the guest, and a
> >> fully-allocated image will take more space on the host than what the
> >> guest is using (that is, a fully-allocated 10G LUKS disk would present
> >> 10G payload to the guest but occupy 10G+1M on the host).
> > 
> > Yes, I had a todo item in the code asking which was better
> > 
> >     /* XXX Should we treat size as being total physical size
> >      * of the image (ie payload + encryption header), or just
> >      * the logical size of the image (ie payload). If the latter
> >      * then we need to extend 'size' to include the header
> >      * size */
> >     qemu_opt_set_number(opts, BLOCK_OPT_SIZE, size, &error_abort);
> > 
> > And Fam suggested the same as you - show full 10 G to the guest.
> > 
> > The complication is that we need to create the backing file
> > before we format the luks header, and we don't know the size
> > of the luks header at that point. So either I could format
> > the luks header into a temporary in-memory buffer, or I have
> > to create the file and then resize it afterwards, or I have
> > to provide some way to calculate the eventual header size
> > prior to creating it. I didn't much like any of those options :-)
> 
> Well, if we hard-code stripes==4000, then we pretty much know that the
> header is just under 1M for the maximum size key (aes-256); and rounding
> up to 1M is nice for all cluster sizes except 2M.  I suppose we could
> fit in 512k if we use a smaller key (aes-128), but would it hurt to just
> hard-code a reservation of 1M?

I actually figured out a way to deal with this - i just have to delay
creation of the underling file, to be done in the callback which initilizes
the luks header region.

> >> Cool!  Would it be worth augmenting the commit message to show a
> >> sequence of commands where you loopback mount a LUKS image file created
> >> by qemu, then wire that up with cryptsetup, as a proof that the two are
> >> compatible implementations?
> > 
> > My intent is to add something to tests/qemu-iotests that will check
> > interoperability between qemu + cryptsetup. Slight complication is
> > that those io tests all expect to run unprivileged. So it'll need
> > a manual step run privileged to create the cryptsetup disk images
> > for testing with.
> 
> We've checked in compressed binary images before; but 1M of key material
> won't compress well.

And realistically it is going to be 10's of MB per image, since I want
the test to verify more than just the header, and there's probably about
10+ different cipher combinations, so it would be many 100's of MBs to
check in. So that won't fly sadly.

> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|