From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSsLP-0007DW-Qy for qemu-devel@nongnu.org; Mon, 08 Feb 2016 15:23:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSsLO-0003AW-QQ for qemu-devel@nongnu.org; Mon, 08 Feb 2016 15:23:35 -0500 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> From: Eric Blake Message-ID: <56B8F940.4020503@redhat.com> Date: Mon, 8 Feb 2016 13:23:28 -0700 MIME-Version: 1.0 In-Reply-To: <20160208162844.GE20236@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nolQ4ALAXoEANqIrE71oAlnU2vOcl4DVl" Subject: Re: [Qemu-devel] [PATCH v2 10/17] block: add generic full disk encryption driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nolQ4ALAXoEANqIrE71oAlnU2vOcl4DVl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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). >=20 > Yes, I had a todo item in the code asking which was better >=20 > /* 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); >=20 > And Fam suggested the same as you - show full 10 G to the guest. >=20 > 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=3D=3D4000, then we pretty much know that th= e 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 create= d >> by qemu, then wire that up with cryptsetup, as a proof that the two ar= e >> compatible implementations? >=20 > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --nolQ4ALAXoEANqIrE71oAlnU2vOcl4DVl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWuPlAAAoJEKeha0olJ0NqxgUH/0su+a09QaypciTq6xoD/eAm 26awDj2m4SDy6wZpVsWx60GTSloBvxBeYJnxyE/q2pyKvlRPJgfj1JIEacushCI8 YOZSdoQCPtIHUWjLh2KyglSk7RUbudPIbrXjGzLRUPfrylFcmJpN4q4+R7V3/SOb 38d/Fw97fngXkENWCoTImVxvGMD+ruFkNV9gXekQ1kFez3SqwqxgQH0LEoPcDDPO /saETu6hxOhIEPVK1U+03ezPfUh7qjS+uoJ88UELyDqdITRX79JmpPxwzqm6nRCY DrGosAUDm6ABKJ26P52Oo878lrW8kT/ipGKWLtvWxVP2HZCLaXgw4E57BCuavY4= =PKtu -----END PGP SIGNATURE----- --nolQ4ALAXoEANqIrE71oAlnU2vOcl4DVl--