From: Kevin Wolf <kwolf@redhat.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
qemu-block@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
qemu-devel@nongnu.org, "Max Reitz" <mreitz@redhat.com>,
"John Snow" <jsnow@redhat.com>
Subject: Re: [PATCH v2 02/11] qcrypto-luks: extend the create options for upcoming encryption key management
Date: Thu, 10 Oct 2019 15:44:23 +0200 [thread overview]
Message-ID: <20191010134423.GC7616@localhost.localdomain> (raw)
In-Reply-To: <20190912223028.18496-3-mlevitsk@redhat.com>
Am 13.09.2019 um 00:30 hat Maxim Levitsky geschrieben:
> Now you can specify which slot to put the encryption key to
> Plus add 'active' option which will let user erase the key secret
> instead of adding it.
> Check that active=true it when creating.
>
> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> diff --git a/qapi/crypto.json b/qapi/crypto.json
> index b2a4cff683..9b83a70634 100644
> --- a/qapi/crypto.json
> +++ b/qapi/crypto.json
> @@ -190,6 +190,20 @@
> # Currently defaults to 'sha256'
> # @hash-alg: the master key hash algorithm
> # Currently defaults to 'sha256'
> +#
> +# @active: Should the new secret be added (true) or erased (false)
> +# (amend only, since 4.2)
> +#
> +# @slot: The slot in which to put/erase the secret
> +# if not given, will select first free slot for secret addtion
> +# and erase all matching keyslots for erase. except last one
> +# (optional, since 4.2)
> +#
> +# @unlock-secret: The secret to use to unlock the image
> +# If not given, will use the secret that was used
> +# when opening the image.
> +# (optional, for amend only, since 4.2)
> +#
> # @iter-time: number of milliseconds to spend in
> # PBKDF passphrase processing. Currently defaults
> # to 2000. (since 2.8)
This approach doesn't look right to me. BlockdevCreateOptions should
describe the state of the image after the operation. You're describing
an update instead (and in a way that doesn't allow you to change
everything that you may want to change, so that you need to call the
operation multiple times).
I imagined the syntax of a blockdev-amend QMP command similar to
x-blockdev-reopen: Describe the full set of options that you want to
have in effect after the operation; if you don't want to change some
option, you just specify it again with its old value.
Specifically for luks, this probably means that you have a @slots, which
is a list that contains at least the secret for each slot, or JSON null
for a slot that should be left empty.
With the same approach, you don't have to make 'size' optional in later
patches, you can just require that the current size is re-specified. And
later, blockdev-amend could actually allow changing the size of images
if you provide a different value.
Kevin
next prev parent reply other threads:[~2019-10-10 13:45 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 [this message]
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 ` [Qemu-devel] [PATCH v2 05/11] block/crypto: implement the encryption key management Maxim Levitsky
2019-10-04 18:41 ` 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=20191010134423.GC7616@localhost.localdomain \
--to=kwolf@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=jsnow@redhat.com \
--cc=mlevitsk@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.