qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-devel@nongnu.org, Eric Blake <eblake@redhat.com>,
	qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 2/2] block: export LUKS specific data to qemu-img info
Date: Tue, 14 Jun 2016 16:47:14 +0100	[thread overview]
Message-ID: <20160614154714.GV4310@redhat.com> (raw)
In-Reply-To: <05bbe389-cb31-6084-7c94-662353e367d2@redhat.com>

On Tue, Jun 14, 2016 at 05:38:36PM +0200, Max Reitz wrote:
> On 14.06.2016 12:56, 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.
> > 
> >     $ qemu-img info ~/VirtualMachines/demo.luks
> >     image: /home/berrange/VirtualMachines/demo.luks
> >     file format: luks
> >     virtual size: 98M (102760448 bytes)
> >     disk size: 100M
> >     encrypted: yes
> >     Format specific information:
> >         ivgen alg: plain64
> >         hash alg: sha1
> >         cipher alg: aes-128
> >         uuid: 6ddee74b-3a22-408c-8909-6789d4fa2594
> >         cipher mode: xts
> >         slots:
> >             [0]:
> >                 active: true
> >                 iters: 572706
> >                 key offset: 4096
> >                 stripes: 4000
> >             [1]:
> >                 active: false
> >                 key offset: 135168
> >             [2]:
> >                 active: false
> >                 key offset: 266240
> >             [3]:
> >                 active: false
> >                 key offset: 397312
> >             [4]:
> >                 active: false
> >                 key offset: 528384
> >             [5]:
> >                 active: false
> >                 key offset: 659456
> >             [6]:
> >                 active: false
> >                 key offset: 790528
> >             [7]:
> >                 active: false
> >                 key offset: 921600
> >         payload offset: 2097152
> >         master key iters: 142375
> > 
> > One somewhat undesirable artifact is that the data fields are
> > printed out in (apparently) random order. This will be addressed
> > later by changing the way the block layer pretty-prints the
> > image specific data.
> > 
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > ---
> >  block/crypto.c       | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  qapi/block-core.json |  7 ++++++-
> >  2 files changed, 65 insertions(+), 1 deletion(-)
> > 
> > diff --git a/block/crypto.c b/block/crypto.c
> > index 758e14e..823572f 100644
> > --- a/block/crypto.c
> > +++ b/block/crypto.c
> > @@ -565,6 +565,63 @@ static int block_crypto_create_luks(const char *filename,
> >                                         filename, opts, errp);
> >  }
> >  
> > +static int block_crypto_get_info_luks(BlockDriverState *bs,
> > +                                      BlockDriverInfo *bdi)
> > +{
> > +    BlockDriverInfo subbdi;
> > +    int ret;
> > +
> > +    ret = bdrv_get_info(bs->file->bs, &subbdi);
> > +    if (ret != 0) {
> > +        return ret;
> > +    }
> > +
> > +    bdi->unallocated_blocks_are_zero = false;
> > +    bdi->can_write_zeroes_with_unmap = false;
> > +    bdi->cluster_size = subbdi.cluster_size;
> > +
> > +    return 0;
> > +}
> > +
> > +static ImageInfoSpecific *
> > +block_crypto_get_specific_info_luks(BlockDriverState *bs)
> > +{
> > +    BlockCrypto *crypto = bs->opaque;
> > +    ImageInfoSpecific *spec_info;
> > +    QCryptoBlockInfo *info;
> > +
> > +    info = qcrypto_block_get_info(crypto->block, NULL);
> > +    if (!info) {
> > +        return NULL;
> > +    }
> > +    if (info->format != Q_CRYPTO_BLOCK_FORMAT_LUKS) {
> > +        qapi_free_QCryptoBlockInfo(info);
> > +        return NULL;
> > +    }
> > +
> > +    spec_info = g_new(ImageInfoSpecific, 1);
> > +    spec_info->type =  IMAGE_INFO_SPECIFIC_KIND_LUKS;
> 
> One space too many.
> 
> > +    spec_info->u.luks.data = g_new(QCryptoBlockInfoLUKS, 1);
> > +    spec_info->u.luks.data->cipher_alg = info->u.luks.cipher_alg;
> > +    spec_info->u.luks.data->cipher_mode = info->u.luks.cipher_mode;
> > +    spec_info->u.luks.data->ivgen_alg = info->u.luks.ivgen_alg;
> > +    spec_info->u.luks.data->has_ivgen_hash_alg =
> > +        info->u.luks.has_ivgen_hash_alg;
> > +    spec_info->u.luks.data->ivgen_hash_alg = info->u.luks.ivgen_hash_alg;
> > +    spec_info->u.luks.data->hash_alg = info->u.luks.hash_alg;
> > +    spec_info->u.luks.data->payload_offset = info->u.luks.payload_offset;
> > +    spec_info->u.luks.data->master_key_iters = info->u.luks.master_key_iters;
> > +    spec_info->u.luks.data->uuid = g_strdup(info->u.luks.uuid);
> > +
> > +    /* Steal the pointer instead of bothering to copy */
> > +    spec_info->u.luks.data->slots = info->u.luks.slots;
> > +    info->u.luks.slots = NULL;
> 
> Why not just steal everything by *spec_info->u.luks.data = info->u.luks
> and then making sure the qapi_free() call below won't free anything in
> there with a memset(&info->u.luks, 0, sizeof(info->u.luks))?

I wish we could, but info->u.luks is an embedded QCryptoBlockInfoLUKS,
not merely a pointer to an independently allocated QCryptoBlockInfoLUKS :-(


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 :|

  reply	other threads:[~2016-06-14 15:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14 10:56 [Qemu-devel] [PATCH v2 0/2] Report format specific info for LUKS block driver Daniel P. Berrange
2016-06-14 10:56 ` [Qemu-devel] [PATCH v2 1/2] crypto: add support for querying parameters for block encryption Daniel P. Berrange
2016-06-14 15:30   ` Max Reitz
2016-06-14 10:56 ` [Qemu-devel] [PATCH v2 2/2] block: export LUKS specific data to qemu-img info Daniel P. Berrange
2016-06-14 15:38   ` Max Reitz
2016-06-14 15:47     ` Daniel P. Berrange [this message]
2016-06-14 15:49       ` Max Reitz
2016-06-14 15:53         ` 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=20160614154714.GV4310@redhat.com \
    --to=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.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).