All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Max Reitz <mreitz@redhat.com>, John Snow <jsnow@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH 06/13] block/crypto: implement the encryption key management
Date: Thu, 30 Jan 2020 18:08:00 +0200	[thread overview]
Message-ID: <b1e56de3c132786ab914cc7c1bea7c5d9c030a24.camel@redhat.com> (raw)
In-Reply-To: <20200128172751.GX1446339@redhat.com>

On Tue, 2020-01-28 at 17:27 +0000, Daniel P. Berrangé wrote:
> On Tue, Jan 14, 2020 at 09:33:43PM +0200, Maxim Levitsky wrote:
> > This implements the encryption key management using the generic code in
> > qcrypto layer and exposes it to the user via qemu-img
> > 
> > This code adds another 'write_func' because the initialization
> > write_func works directly on the underlying file, and amend
> > works on instance of luks device.
> > 
> > This commit also adds a 'hack/workaround' I and Kevin Wolf (thanks)
> > made to make the driver both support write sharing (to avoid breaking the users),
> > and be safe against concurrent  metadata update (the keyslots)
> > 
> > Eventually the write sharing for luks driver will be deprecated
> > and removed together with this hack.
> > 
> > The hack is that we ask (as a format driver) for BLK_PERM_CONSISTENT_READ
> > and then when we want to update the keys, we unshare that permission.
> > So if someone else has the image open, even readonly, encryption
> > key update will fail gracefully.
> > 
> > Also thanks to Daniel Berrange for the idea of
> > unsharing read, rather that write permission which allows
> > to avoid cases when the other user had opened the image read-only.
> > 
> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > ---
> >  block/crypto.c | 130 +++++++++++++++++++++++++++++++++++++++++++++++--
> >  block/crypto.h |  31 ++++++++++++
> >  2 files changed, 158 insertions(+), 3 deletions(-)
> > 
> > @@ -148,6 +167,22 @@ static QemuOptsList block_crypto_create_opts_luks = {
> >  };
> >  
> >  
> > +static QemuOptsList block_crypto_amend_opts_luks = {
> > +    .name = "crypto",
> > +    .head = QTAILQ_HEAD_INITIALIZER(block_crypto_create_opts_luks.head),
> > +    .desc = {
> > +        BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.0."),
> > +        BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.1."),
> > +        BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.2."),
> > +        BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.3."),
> > +        BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.4."),
> > +        BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.5."),
> > +        BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.6."),
> > +        BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.7."),
> 
> I'd probably suggest  "key.0" or "keyslot.0" as a name.
To be honest, I don't like either of these. 

I don't like the 'keys'
array, because it is a bit misleading, as basically each 'key' is a command
that can add/erase an arbitrary keyslot.

I would call this 'command' or cmd at least.

Also note that the 'keys' here is passed as is to qmp parser so if I change it here, I will have probably
to update the qmp version as well and there the 'keys' name is more or less agreed upon.
Thoughts?


> 
> > +        { /* end of list */ }
> > +    },
> > +};
> > +
> 
> 
> > @@ -661,6 +696,95 @@ block_crypto_get_specific_info_luks(BlockDriverState *bs, Error **errp)
> >      return spec_info;
> >  }
> >  
> > +static int
> > +block_crypto_amend_options(BlockDriverState *bs,
> > +                           QemuOpts *opts,
> > +                           BlockDriverAmendStatusCB *status_cb,
> > +                           void *cb_opaque,
> > +                           bool force,
> > +                           Error **errp)
> 
> This method should have a "_luks" suffix since...

Oops, thanks!
> 
> > +{
> > +    BlockCrypto *crypto = bs->opaque;
> > +    QDict *cryptoopts = NULL;
> > +    QCryptoBlockAmendOptions *amend_options = NULL;
> > +    int ret;
> > +
> > +    assert(crypto);
> > +    assert(crypto->block);
> > +    crypto->updating_keys = true;
> > +
> > +    ret = bdrv_child_refresh_perms(bs, bs->file, errp);
> > +    if (ret < 0) {
> > +        goto cleanup;
> > +    }
> > +
> > +    cryptoopts = qemu_opts_to_qdict(opts, NULL);
> > +    qdict_put_str(cryptoopts, "format", "luks");
> 
> ...it is hardcoded here to assume luks.
> 
> > +    amend_options = block_crypto_amend_opts_init(cryptoopts, errp);
> > +    if (!amend_options) {
> > +        ret = -EINVAL;
> > +        goto cleanup;
> > +    }
> > +
> > +    ret = qcrypto_block_amend_options(crypto->block,
> > +                                      block_crypto_read_func,
> > +                                      block_crypto_write_func,
> > +                                      bs,
> > +                                      amend_options,
> > +                                      force,
> > +                                      errp);
> > +cleanup:
> > +    crypto->updating_keys = false;
> > +    bdrv_child_refresh_perms(bs, bs->file, errp);
> > +    qapi_free_QCryptoBlockAmendOptions(amend_options);
> > +    qobject_unref(cryptoopts);
> > +    return ret;
> > +}
> 
> With the minor changes above
> 
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

Best regards,
	Thanks for the review,
		Maxim Levitsky


> 
> 
> Regards,
> Daniel




  reply	other threads:[~2020-01-30 16:08 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14 19:33 [PATCH 00/13] LUKS: encryption slot management using amend interface Maxim Levitsky
2020-01-14 19:33 ` [PATCH 01/13] qcrypto: add generic infrastructure for crypto options amendment Maxim Levitsky
2020-01-28 16:59   ` Daniel P. Berrangé
2020-01-29 17:49     ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 02/13] qcrypto-luks: implement encryption key management Maxim Levitsky
2020-01-21  7:54   ` Markus Armbruster
2020-01-21 13:13     ` Maxim Levitsky
2020-01-28 17:11       ` Daniel P. Berrangé
2020-01-28 17:32         ` Daniel P. Berrangé
2020-01-29 17:54           ` Maxim Levitsky
2020-01-30 12:38           ` Kevin Wolf
2020-01-30 12:53             ` Daniel P. Berrangé
2020-01-30 14:23               ` Kevin Wolf
2020-01-30 14:30                 ` Daniel P. Berrangé
2020-01-30 14:53                 ` Markus Armbruster
2020-01-30 14:47               ` Markus Armbruster
2020-01-30 15:01                 ` Daniel P. Berrangé
2020-01-30 16:37                   ` Markus Armbruster
2020-02-05  8:24                     ` Markus Armbruster
2020-02-05  9:30                       ` Kevin Wolf
2020-02-05 10:03                         ` Markus Armbruster
2020-02-05 11:02                           ` Kevin Wolf
2020-02-05 14:31                             ` Markus Armbruster
2020-02-06 13:44                               ` Markus Armbruster
2020-02-06 13:49                                 ` Daniel P. Berrangé
2020-02-06 14:20                                   ` Max Reitz
2020-02-05 10:23                         ` Daniel P. Berrangé
2020-02-05 14:31                           ` Markus Armbruster
2020-02-06 13:20                             ` Markus Armbruster
2020-02-06 13:36                               ` Daniel P. Berrangé
2020-02-06 14:25                                 ` Kevin Wolf
2020-02-06 15:19                                   ` Markus Armbruster
2020-02-06 15:23                                     ` Maxim Levitsky
2020-01-30 15:45                 ` Maxim Levitsky
2020-01-28 17:21   ` Daniel P. Berrangé
2020-01-30 12:58     ` Maxim Levitsky
2020-02-15 14:51   ` QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management) Markus Armbruster
2020-02-16  8:05     ` Maxim Levitsky
2020-02-17  6:45       ` QAPI schema for desired state of LUKS keyslots Markus Armbruster
2020-02-17  8:19         ` Maxim Levitsky
2020-02-17 10:37     ` QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management) Kevin Wolf
2020-02-17 11:07       ` Maxim Levitsky
2020-02-24 14:46         ` Daniel P. Berrangé
2020-02-24 14:50           ` Maxim Levitsky
2020-02-17 12:28       ` QAPI schema for desired state of LUKS keyslots Markus Armbruster
2020-02-17 12:44         ` Eric Blake
2020-02-24 14:43         ` Daniel P. Berrangé
2020-02-24 14:45     ` QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management) Daniel P. Berrangé
2020-02-25 12:15     ` Max Reitz
2020-02-25 16:48       ` QAPI schema for desired state of LUKS keyslots Markus Armbruster
2020-02-25 17:00         ` Max Reitz
2020-02-26  7:28           ` Markus Armbruster
2020-02-26  9:18             ` Maxim Levitsky
2020-02-25 17:18         ` Daniel P. Berrangé
2020-03-03  9:18     ` QAPI schema for desired state of LUKS keyslots (was: [PATCH 02/13] qcrypto-luks: implement encryption key management) Maxim Levitsky
2020-03-05 12:15       ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 03/13] block: amend: add 'force' option Maxim Levitsky
2020-01-14 19:33 ` [PATCH 04/13] block: amend: separate amend and create options for qemu-img Maxim Levitsky
2020-01-28 17:23   ` Daniel P. Berrangé
2020-01-30 15:54     ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 05/13] block/crypto: rename two functions Maxim Levitsky
2020-01-14 19:33 ` [PATCH 06/13] block/crypto: implement the encryption key management Maxim Levitsky
2020-01-28 17:27   ` Daniel P. Berrangé
2020-01-30 16:08     ` Maxim Levitsky [this message]
2020-01-14 19:33 ` [PATCH 07/13] qcow2: extend qemu-img amend interface with crypto options Maxim Levitsky
2020-01-28 17:30   ` Daniel P. Berrangé
2020-01-30 16:09     ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 08/13] iotests: filter few more luks specific create options Maxim Levitsky
2020-01-28 17:36   ` Daniel P. Berrangé
2020-01-30 16:12     ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 09/13] qemu-iotests: qemu-img tests for luks key management Maxim Levitsky
2020-01-14 19:33 ` [PATCH 10/13] block: add generic infrastructure for x-blockdev-amend qmp command Maxim Levitsky
2020-01-21  7:59   ` Markus Armbruster
2020-01-21 13:58     ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 11/13] block/crypto: implement blockdev-amend Maxim Levitsky
2020-01-28 17:40   ` Daniel P. Berrangé
2020-01-30 16:24     ` Maxim Levitsky
2020-01-14 19:33 ` [PATCH 12/13] block/qcow2: " Maxim Levitsky
2020-01-28 17:41   ` Daniel P. Berrangé
2020-01-14 19:33 ` [PATCH 13/13] iotests: add tests for blockdev-amend Maxim Levitsky
2020-01-14 21:16 ` [PATCH 00/13] LUKS: encryption slot management using amend interface no-reply
2020-01-16 14:01   ` Maxim Levitsky
2020-01-14 21:17 ` no-reply
2020-01-16 14:19   ` Maxim Levitsky

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=b1e56de3c132786ab914cc7c1bea7c5d9c030a24.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=jsnow@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.