[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 10/17] block: add generic full disk encryptio
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH v2 10/17] block: add generic full disk encryption driver |
Date: |
Mon, 8 Feb 2016 13:23:28 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 |
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?
>> 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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature