From: "Daniel P. Berrange" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Michael Roth <mdroth@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [PATCH v1 2/6] block: export LUKS specific data to qemu-img info
Date: Tue, 7 Jun 2016 16:51:34 +0100 [thread overview]
Message-ID: <20160607155134.GR20196@redhat.com> (raw)
In-Reply-To: <5756E9E8.8000908@redhat.com>
On Tue, Jun 07, 2016 at 09:36:08AM -0600, Eric Blake wrote:
> On 06/07/2016 04:11 AM, Daniel P. Berrange wrote:
> > +++ b/qapi/block-core.json
> > @@ -74,6 +74,37 @@
> > 'extents': ['ImageInfo']
> > } }
> >
> > +
> > +{ '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?
Essentially yes, and this is something I meant to mention in
the cover letter.
I wasn't really sure on the best approach to take here. I
could certainly re-use the QCrypto QAPI object by doing
{ 'union': 'ImageInfoSpecific',
'data': {
'qcow2': 'ImageInfoSpecificQCow2',
'vmdk': 'ImageInfoSpecificVmdk',
'luks': 'QCryptoBlockInfoLUKS',
} }
I was not sure if that was a good idea or whether it is better
to have isolation between the crypto layer and block layer, as
safety net in case we need them to diverge. The main thing was
whether the data we report from the block driver will need to
include extra stuff not present in QCryptoBlockInfoLUKS, perhaps
related to the backing file/format.
I guess another option would be for ImageInfoSpecificLUKS
to sub-class QCryptoBlockInfoLUKS in that case.
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 :|
next prev parent reply other threads:[~2016-06-07 15:51 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 10:11 [Qemu-devel] [PATCH v1 0/6] Report format specific info for LUKS block driver Daniel P. Berrange
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 1/6] crypto: add support for querying parameters for block encryption Daniel P. Berrange
2016-06-07 14:17 ` Eric Blake
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 2/6] block: export LUKS specific data to qemu-img info Daniel P. Berrange
2016-06-07 15:36 ` Eric Blake
2016-06-07 15:51 ` Daniel P. Berrange [this message]
2016-06-07 16:11 ` Eric Blake
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 3/6] qapi: assert that visitor impls have required callbacks Daniel P. Berrange
2016-06-07 15:40 ` Eric Blake
2016-06-07 15:46 ` Daniel P. Berrange
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 4/6] qapi: add a text output visitor for pretty printing types Daniel P. Berrange
2016-06-07 16:09 ` Eric Blake
2016-06-07 16:20 ` Daniel P. Berrange
2016-06-07 16:40 ` Eric Blake
2016-06-07 16:45 ` Daniel P. Berrange
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 5/6] qapi: generate a qapi_stringify_TYPENAME method for all types Daniel P. Berrange
2016-06-07 16:23 ` Eric Blake
2016-06-07 10:11 ` [Qemu-devel] [PATCH v1 6/6] block: convert to use qapi_stringify_ImageInfoSpecific Daniel P. Berrange
2016-06-07 16:59 ` Eric Blake
2016-06-07 12:04 ` [Qemu-devel] [PATCH v1 0/6] Report format specific info for LUKS block driver Eric Blake
2016-06-07 14:35 ` Daniel P. Berrange
2016-06-14 13:56 ` Max Reitz
2016-06-14 14:05 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160607155134.GR20196@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).