qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org,
	"Maxim Levitsky" <mlevitsk@redhat.com>,
	"Max Reitz" <mreitz@redhat.com>, "John Snow" <jsnow@redhat.com>
Subject: Re: [PATCH 02/13] qcrypto-luks: implement encryption key management
Date: Thu, 06 Feb 2020 16:19:56 +0100	[thread overview]
Message-ID: <87pnerd9pf.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20200206142558.GB4926@linux.fritz.box> (Kevin Wolf's message of "Thu, 6 Feb 2020 15:25:58 +0100")

Kevin Wolf <kwolf@redhat.com> writes:

> Am 06.02.2020 um 14:36 hat Daniel P. Berrangé geschrieben:
>> On Thu, Feb 06, 2020 at 02:20:11PM +0100, Markus Armbruster wrote:
>> > One more question regarding the array in
>> > 
>> >     { 'struct': 'QCryptoBlockAmendOptionsLUKS',
>> >       'data' : {
>> >                 'keys': ['LUKSKeyslotUpdate'],
>> >                  '*unlock-secret' : 'str' } }
>> > 
>> > Why an array?  Do we really need multiple keyslot updates in one amend
>> > operation?
>> 
>> I think it it is unlikely we'd use this in libvirt. In the case of wanting
>> to *change* a key, it is safer to do a sequence of "add key" and then
>> "remove key". If you combine them into the same operation, and you get
>> an error back, it is hard to know /where/ it failed ? was the new key
>> added or not ?
>
> I think the array came in because of the "describe the new state"
> approach. The state has eight keyslots, so in order to fully describe
> the new state, you would have to be able to pass multiple slots at once.

I see.

Of course, it can also describe multiple new states for the same slot.

Example:

    [{'state': 'active', 'keyslot': 0, 'secret': 'sec0'},
     {'state': 'active', 'keyslot': 0, 'secret': 'sec1'}]

    where slot 0's old state is 'inactive'.

Which one is the new state?

If we execute the array elements one by one, this first makes slot 0
active with secret 'sec0', then tries to make it active with secret
'sec1', which fails.  Simple enough, but it's not really "describe the
new state", it's still "specify a series of state transitions".

If we merge the array elements into a description of the new state of
all eight slots, where a slot's description can be "same as old state",
then this makes slot 0 active with either secret 'sec0' or 'sec1',
depending on how we resolve the conflict.  We could even make conflicts
an error, and then this would fail without changing anything.

What do we want?

Is this worth the trouble?



  reply	other threads:[~2020-02-06 15:21 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 [this message]
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
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=87pnerd9pf.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@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 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).