qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-block@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Max Reitz" <mreitz@redhat.com>,
	"Maxim Levitsky" <mlevitsk@redhat.com>,
	"John Snow" <jsnow@redhat.com>
Subject: [Qemu-devel] [PATCH v2 05/11] block/crypto: implement the encryption key management
Date: Fri, 13 Sep 2019 01:30:22 +0300	[thread overview]
Message-ID: <20190912223028.18496-6-mlevitsk@redhat.com> (raw)
In-Reply-To: <20190912223028.18496-1-mlevitsk@redhat.com>

This implements the encryption key management
using the generic code in qcrypto layer
(currently only for qemu-img amend)

This code adds another 'write_func' because the initialization
write_func works directly on the underlying file,
because during the creation, there is no open instance
of the luks driver, but during regular use, we have it,
and should use it instead.


This commit also adds a	'hack/workaround' I and	Kevin Wolf (thanks)
made to	make the driver	still support write sharing,
but be safe against concurrent  metadata update (the keys)
Eventually 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 always
(technically always unless opened with BDRV_O_NO_IO)

and then when we want to update	the keys, we
unshare	that permission. So if someone else
has the	image open, even readonly, this	will fail.

Also thanks to Daniel Berrange for the variant of
that hack that involves	asking for read,
rather that write permission

Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
---
 block/crypto.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 115 insertions(+), 3 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index a6a3e1f1d8..f42fa057e6 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -36,6 +36,7 @@ typedef struct BlockCrypto BlockCrypto;
 
 struct BlockCrypto {
     QCryptoBlock *block;
+    bool updating_keys;
 };
 
 
@@ -70,6 +71,24 @@ static ssize_t block_crypto_read_func(QCryptoBlock *block,
     return ret;
 }
 
+static ssize_t block_crypto_write_func(QCryptoBlock *block,
+                                       size_t offset,
+                                       const uint8_t *buf,
+                                       size_t buflen,
+                                       void *opaque,
+                                       Error **errp)
+{
+    BlockDriverState *bs = opaque;
+    ssize_t ret;
+
+    ret = bdrv_pwrite(bs->file, offset, buf, buflen);
+    if (ret < 0) {
+        error_setg_errno(errp, -ret, "Could not write encryption header");
+        return ret;
+    }
+    return ret;
+}
+
 
 struct BlockCryptoCreateData {
     BlockBackend *blk;
@@ -647,6 +666,100 @@ 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)
+{
+    BlockCrypto *crypto = bs->opaque;
+    QDict *cryptoopts = NULL;
+    QCryptoBlockCreateOptions *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_filtered(opts, NULL,
+                                             &block_crypto_create_opts_luks,
+                                             true);
+
+    qdict_put_str(cryptoopts, "format", "luks");
+    amend_options = block_crypto_create_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_QCryptoBlockCreateOptions(amend_options);
+    qobject_unref(cryptoopts);
+    return ret;
+}
+
+
+static void
+block_crypto_child_perms(BlockDriverState *bs, BdrvChild *c,
+                         const BdrvChildRole *role,
+                         BlockReopenQueue *reopen_queue,
+                         uint64_t perm, uint64_t shared,
+                         uint64_t *nperm, uint64_t *nshared)
+{
+
+    BlockCrypto *crypto = bs->opaque;
+
+    /*
+     * Ask for consistent read permission so that if
+     * someone else tries to open this image with this permission
+     * neither will be able to edit encryption keys
+     */
+    if (!(bs->open_flags & BDRV_O_NO_IO)) {
+        perm |= BLK_PERM_CONSISTENT_READ;
+    }
+
+    /*
+     * This driver doesn't modify LUKS metadata except
+     * when updating the encryption slots.
+     * Thus unlike a proper format driver we don't ask for
+     * shared write permission. However we need it
+     * when we area updating keys, to ensure that only we
+     * had opened the device r/w
+     *
+     * Encryption update will set the crypto->updating_keys
+     * during that period and refresh permissions
+     *
+     */
+
+    if (crypto->updating_keys) {
+        /*need exclusive write access for header update  */
+        perm |= BLK_PERM_WRITE;
+        shared &= ~(BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE);
+    }
+
+    bdrv_filter_default_perms(bs, c, role, reopen_queue,
+            perm, shared, nperm, nshared);
+}
+
+
 static const char *const block_crypto_strong_runtime_opts[] = {
     BLOCK_CRYPTO_OPT_LUKS_KEY_SECRET,
 
@@ -659,9 +772,7 @@ static BlockDriver bdrv_crypto_luks = {
     .bdrv_probe         = block_crypto_probe_luks,
     .bdrv_open          = block_crypto_open_luks,
     .bdrv_close         = block_crypto_close,
-    /* This driver doesn't modify LUKS metadata except when creating image.
-     * Allow share-rw=on as a special case. */
-    .bdrv_child_perm    = bdrv_filter_default_perms,
+    .bdrv_child_perm    = block_crypto_child_perms,
     .bdrv_co_create     = block_crypto_co_create_luks,
     .bdrv_co_create_opts = block_crypto_co_create_opts_luks,
     .bdrv_co_truncate   = block_crypto_co_truncate,
@@ -674,6 +785,7 @@ static BlockDriver bdrv_crypto_luks = {
     .bdrv_getlength     = block_crypto_getlength,
     .bdrv_get_info      = block_crypto_get_info_luks,
     .bdrv_get_specific_info = block_crypto_get_specific_info_luks,
+    .bdrv_amend_options = block_crypto_amend_options,
 
     .strong_runtime_opts = block_crypto_strong_runtime_opts,
 };
-- 
2.17.2



  parent reply	other threads:[~2019-09-12 22:36 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-12 22:30 [Qemu-devel] [PATCH v2 00/11] RFC crypto/luks: encryption key managment using amend interface Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 01/11] qcrypto: add suport for amend options Maxim Levitsky
2019-09-23 13:08   ` Eric Blake
2019-09-23 13:24     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 02/11] qcrypto-luks: extend the create options for upcoming encryption key management Maxim Levitsky
2019-10-04 17:42   ` Max Reitz
2019-11-08  9:28     ` Maxim Levitsky
2019-11-08 10:48       ` Max Reitz
2019-11-08 11:48         ` Maxim Levitsky
2019-10-07  7:49   ` [Qemu-devel] " Markus Armbruster
2019-11-08  9:28     ` Maxim Levitsky
2019-10-10 13:44   ` Kevin Wolf
2019-11-08 10:04     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 03/11] qcrypto-luks: implement the " Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 04/11] block: amend: add 'force' option Maxim Levitsky
2019-09-12 22:30 ` Maxim Levitsky [this message]
2019-10-04 18:41   ` [PATCH v2 05/11] block/crypto: implement the encryption key management Max Reitz
2019-11-08  9:30     ` Maxim Levitsky
2019-11-08 10:49       ` Max Reitz
2019-11-08 11:04         ` Maxim Levitsky
2019-11-08 13:12           ` Max Reitz
2019-11-08 13:20             ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 06/11] qcow2: implement crypto amend options Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 07/11] block: add x-blockdev-amend qmp command Maxim Levitsky
2019-10-04 18:53   ` Max Reitz
2019-11-08  9:26     ` Maxim Levitsky
2019-11-08 10:36       ` Max Reitz
2019-11-08 13:37         ` Maxim Levitsky
2019-11-08  9:27     ` Maxim Levitsky
2019-10-07  7:53   ` [Qemu-devel] " Markus Armbruster
2019-11-08 15:38     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 08/11] block/crypto: implement blockdev-amend Maxim Levitsky
2019-10-07  7:58   ` Markus Armbruster
2019-11-08 15:36     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 09/11] block/qcow2: " Maxim Levitsky
2019-10-04 19:03   ` Max Reitz
2019-10-07  8:04     ` Markus Armbruster
2019-11-08 15:14       ` Maxim Levitsky
2019-11-08 15:18     ` Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 10/11] iotests: filter few more luks specific create options Maxim Levitsky
2019-09-12 22:30 ` [Qemu-devel] [PATCH v2 11/11] iotests : add tests for encryption key management Maxim Levitsky
2019-10-04 19:11   ` Max Reitz
2019-11-08  9:28     ` Maxim Levitsky
2019-09-20 21:14 ` [Qemu-devel] [PATCH v2 00/11] RFC crypto/luks: encryption key managment using amend interface John Snow
2019-09-22  8:17   ` Maxim Levitsky
2019-10-07  8:05     ` Markus Armbruster
2019-11-06 16:43       ` Maxim Levitsky
2019-09-30 17:11   ` Maxim Levitsky
2019-10-04 19:10 ` Max Reitz
2019-11-08 15:07   ` Maxim Levitsky
2019-11-12 11:58     ` Max Reitz
2019-11-12 12:07       ` 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=20190912223028.18496-6-mlevitsk@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 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).