From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58474) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aT50t-0007Ov-Fj for qemu-devel@nongnu.org; Tue, 09 Feb 2016 04:55:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aT50s-0001Pk-56 for qemu-devel@nongnu.org; Tue, 09 Feb 2016 04:55:15 -0500 Date: Tue, 9 Feb 2016 09:55:03 +0000 From: "Daniel P. Berrange" Message-ID: <20160209095503.GA24614@redhat.com> References: <1453311539-1193-1-git-send-email-berrange@redhat.com> <1453311539-1193-11-git-send-email-berrange@redhat.com> <56B5203B.1010209@redhat.com> <20160208162844.GE20236@redhat.com> <56B8F940.4020503@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56B8F940.4020503@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 10/17] block: add generic full disk encryption driver Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, qemu-block@nongnu.org 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 :|