From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45303) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAJ3B-0007S4-7J for qemu-devel@nongnu.org; Tue, 07 Jun 2016 11:36:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAJ39-0001cl-Vu for qemu-devel@nongnu.org; Tue, 07 Jun 2016 11:36:17 -0400 References: <1465294275-8733-1-git-send-email-berrange@redhat.com> <1465294275-8733-3-git-send-email-berrange@redhat.com> From: Eric Blake Message-ID: <5756E9E8.8000908@redhat.com> Date: Tue, 7 Jun 2016 09:36:08 -0600 MIME-Version: 1.0 In-Reply-To: <1465294275-8733-3-git-send-email-berrange@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Do2Vxqri9vHbEkD4tIfFFhIUwWRgwv2gD" Subject: Re: [Qemu-devel] [PATCH v1 2/6] block: export LUKS specific data to qemu-img info 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, Kevin Wolf , Max Reitz , Markus Armbruster , Michael Roth This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Do2Vxqri9vHbEkD4tIfFFhIUwWRgwv2gD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/07/2016 04:11 AM, Daniel P. Berrange wrote: > The qemu-img info command has the ability to expose format > specific metadata about volumes. Wire up this facility for > the LUKS driver to report on cipher configuration and key > slot usage. >=20 >=20 > One somewhat undesirable artifact is that the data fields are > printed out in (apparantly) random order. This will be addressed s/apparantly/apparently/ > later by changing the way the block layer pretty-prints the > image specific data. Ah, so your new visitor pretty-prints HMP, not JSON. Okay, then I get to review it after all, and it is probably a good addition in parallel to my JSON printer. >=20 > Signed-off-by: Daniel P. Berrange > --- > block/crypto.c | 80 ++++++++++++++++++++++++++++++++++++++++++++= ++++++++ > qapi/block-core.json | 34 +++++++++++++++++++++- > 2 files changed, 113 insertions(+), 1 deletion(-) >=20 > + > + spec_info =3D g_new(ImageInfoSpecific, 1); > + spec_info->type =3D IMAGE_INFO_SPECIFIC_KIND_LUKS; > + spec_info->u.luks.data =3D g_new(ImageInfoSpecificLUKS, 1); > + spec_info->u.luks.data->cipher_alg =3D info->u.luks.cipher_alg; > + spec_info->u.luks.data->cipher_mode =3D info->u.luks.cipher_mode; > + spec_info->u.luks.data->ivgen_alg =3D info->u.luks.ivgen_alg; > + spec_info->u.luks.data->has_ivgen_hash_alg =3D > + info->u.luks.has_ivgen_hash_alg; > + spec_info->u.luks.data->ivgen_hash_alg =3D info->u.luks.ivgen_hash= _alg; > + spec_info->u.luks.data->hash_alg =3D info->u.luks.hash_alg; > + spec_info->u.luks.data->payload_offset =3D info->u.luks.payload_of= fset; > + spec_info->u.luks.data->master_key_iters =3D info->u.luks.master_k= ey_iters; > + spec_info->u.luks.data->uuid =3D g_strdup(info->u.luks.uuid); My clone visitor patches would help here. > +++ b/qapi/block-core.json > @@ -74,6 +74,37 @@ > 'extents': ['ImageInfo'] > } } > =20 > + > +{ 'struct': 'ImageInfoSpecificLUKSSlot', > + 'data': {'active': 'bool', > + 'iters': 'int', > + 'stripes': 'int', > + 'key-offset': 'int' } } Missing documentation, but why do you need it, since it is identical to QCryptoBlockInfoLUKSSlot in the previous patch? > + > +## > +# @ImageInfoSpecificLUKS: > +# > +# @cipher-alg: the cipher algorithm for data encryption > +# @cipher-mode: the cipher mode for data encryption > +# @ivgen-alg: the initialization vector generator > +# @ivgen-hash-alg: the initialization vector generator hash > +# @hash-alg: the master key hash algorithm > +# Not all the members are documented, but isn't this identical to QCryptoBlockInfoLUKS in the previous patch? > +# Since: 2.7 > +## > +{ 'struct': 'ImageInfoSpecificLUKS', > + 'data': { > + 'cipher-alg': 'QCryptoCipherAlgorithm', > + 'cipher-mode': 'QCryptoCipherMode', > + 'ivgen-alg': 'QCryptoIVGenAlgorithm', > + '*ivgen-hash-alg': 'QCryptoHashAlgorithm', > + 'hash-alg': 'QCryptoHashAlgorithm', > + 'payload-offset': 'int', > + 'master-key-iters': 'int', > + 'uuid': 'str', > + 'slots': [ 'ImageInfoSpecificLUKSSlot' ] > + } } > + > ## > # @ImageInfoSpecific: > # > @@ -85,7 +116,8 @@ > { 'union': 'ImageInfoSpecific', > 'data': { > 'qcow2': 'ImageInfoSpecificQCow2', > - 'vmdk': 'ImageInfoSpecificVmdk' > + 'vmdk': 'ImageInfoSpecificVmdk', > + 'luks': 'ImageInfoSpecificLUKS' I guess the difference is whether you are giving the info on a LUKS image regardless of underlying storage, vs. on a qcow2 image with LUKS encryption. Still, can't we reuse the type, rather than duplicate it? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --Do2Vxqri9vHbEkD4tIfFFhIUwWRgwv2gD 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/ iQEcBAEBCAAGBQJXVunoAAoJEKeha0olJ0NqhCoH/17iK5uBIcutuXNT6osfF0CY IWLYKJr3EOfOsEclhOUIiY9H9hW4cZdMEZcquZ7i5tA2BSYrguac1i2iH25yDage WtHJKENfmaA2qVvt5qr+tCMi1OmJ16ZTZoGt2rhbIMc17UvOl8PT5Hnb+l3gev+e NBj1YDPN3B5JgxKHh9dc/x0hy/jSQkoWlfiVUnw1giXH+O3HY4yOYN2zRj8FkE/B XPBwwaQFpeM6CfxcuuASfLXbKEEvVhvCRbCbixwyblzRTZlaLkaShkQAIHmxcYF7 JJVTt51eIyfrx6L9Vq3VEtuUdgY5fxI/NMJ6zFrYzIk1y3v5nAL0PiWCBz8Q0d4= =jdem -----END PGP SIGNATURE----- --Do2Vxqri9vHbEkD4tIfFFhIUwWRgwv2gD--