From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dNh6H-0000hn-2D for qemu-devel@nongnu.org; Wed, 21 Jun 2017 10:59:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dNh6D-00024r-5d for qemu-devel@nongnu.org; Wed, 21 Jun 2017 10:59:21 -0400 From: Max Reitz References: <20170619173455.18805-1-berrange@redhat.com> <20170619173455.18805-14-berrange@redhat.com> <79345f33-2cf6-bec1-c96d-981fc7e3fedd@redhat.com> Message-ID: <48afe1ce-e500-e7a7-18de-2ed67d808df3@redhat.com> Date: Wed, 21 Jun 2017 16:59:02 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pG4e4BrB2c9b9eSVQQ23QwwakQbFib10O" Subject: Re: [Qemu-devel] [PATCH v9 13/20] qcow2: add support for LUKS encryption format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: qemu-block@nongnu.org, Eric Blake , Kevin Wolf , Alberto Garcia This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pG4e4BrB2c9b9eSVQQ23QwwakQbFib10O From: Max Reitz To: "Daniel P. Berrange" , qemu-devel@nongnu.org Cc: qemu-block@nongnu.org, Eric Blake , Kevin Wolf , Alberto Garcia Message-ID: <48afe1ce-e500-e7a7-18de-2ed67d808df3@redhat.com> Subject: Re: [PATCH v9 13/20] qcow2: add support for LUKS encryption format References: <20170619173455.18805-1-berrange@redhat.com> <20170619173455.18805-14-berrange@redhat.com> <79345f33-2cf6-bec1-c96d-981fc7e3fedd@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2017-06-21 16:46, Max Reitz wrote: > On 2017-06-21 16:42, Max Reitz wrote: >> On 2017-06-19 19:34, Daniel P. Berrange wrote: >>> This adds support for using LUKS as an encryption format >>> with the qcow2 file, using the new encrypt.format parameter >>> to request "luks" format. e.g. >>> >>> # qemu-img create --object secret,data=3D123456,id=3Dsec0 \ >>> -f qcow2 -o encrypt.format=3Dluks,encrypt.key-secret=3Dsec0 \ >>> test.qcow2 10G >>> >>> The legacy "encryption=3Don" parameter still results in >>> creation of the old qcow2 AES format (and is equivalent >>> to the new 'encryption-format=3Daes'). e.g. the following are >>> equivalent: >>> >>> # qemu-img create --object secret,data=3D123456,id=3Dsec0 \ >>> -f qcow2 -o encryption=3Don,encrypt.key-secret=3Dsec0 \ >>> test.qcow2 10G >>> >>> # qemu-img create --object secret,data=3D123456,id=3Dsec0 \ >>> -f qcow2 -o encryption-format=3Daes,encrypt.key-secret=3Dsec0 = \ >>> test.qcow2 10G >>> >>> With the LUKS format it is necessary to store the LUKS >>> partition header and key material in the QCow2 file. This >>> data can be many MB in size, so cannot go into the QCow2 >>> header region directly. Thus the spec defines a FDE >>> (Full Disk Encryption) header extension that specifies >>> the offset of a set of clusters to hold the FDE headers, >>> as well as the length of that region. The LUKS header is >>> thus stored in these extra allocated clusters before the >>> main image payload. >>> >>> Aside from all the cryptographic differences implied by >>> use of the LUKS format, there is one further key difference >>> between the use of legacy AES and LUKS encryption in qcow2. >>> For LUKS, the initialiazation vectors are generated using >>> the host physical sector as the input, rather than the >>> guest virtual sector. This guarantees unique initialization >>> vectors for all sectors when qcow2 internal snapshots are >>> used, thus giving stronger protection against watermarking >>> attacks. >>> >>> Reviewed-by: Eric Blake >>> Reviewed-by: Alberto Garcia >>> Signed-off-by: Daniel P. Berrange >>> --- >>> block/qcow2-cluster.c | 4 +- >>> block/qcow2-refcount.c | 10 ++ >>> block/qcow2.c | 268 +++++++++++++++++++++++++++++++++++= +++------ >>> block/qcow2.h | 9 ++ >>> qapi/block-core.json | 5 +- >>> tests/qemu-iotests/082.out | 270 +++++++++++++++++++++++++++++++++++= +--------- >>> 6 files changed, 478 insertions(+), 88 deletions(-) >> >> Reviewed-by: Max Reitz >=20 > (But due to the split of do_perform_cow(), this will need the same > changes that patch 10 and 11 will need (in this case only contextual, i= n > the cases of 10 and 11 there are also functional changes required).) (Turns out it will need a functional change, too, because do_perform_cow_encrypt() doesn't take the host offset yet.) Max --pG4e4BrB2c9b9eSVQQ23QwwakQbFib10O 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 iQEvBAEBCAAZBQJZSom2EhxtcmVpdHpAcmVkaGF0LmNvbQAKCRD0B9sAYdXPQGEn CACwi/U+Rg7mk8YKXY742W9Sx+UoBikDFJldqH3jXDQFsHiIWalh31MfMz67VnUE kc8oe7jnBOCkqXrlhXYLU0r83qDZyxNbaiSE6gCKOtKH+LPo6YqK9YRoJK7IHT4Z A0IzAk8R7/AeTj7HuZiaVR8YyV8NYjbam+OIxoPdSQLauHnGfw4/HgietLInt+Xn /iNO57E5aavHsmS0uPag1Yt4coxwe4mnLMYjA1NmVsUPH2/t3tZphqk5bG0KgANX 6HIUzCJdB9VPM7huJp9HqQctcxUFFgdeKErcClJ5aCqBLmnedDLfkIcZqzRtnIw+ vA756yCivYHi2w7IkErRIve9 =PydH -----END PGP SIGNATURE----- --pG4e4BrB2c9b9eSVQQ23QwwakQbFib10O--