From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Kevin Wolf <kwolf@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: QAPI schema for desired state of LUKS keyslots
Date: Tue, 25 Feb 2020 17:18:23 +0000 [thread overview]
Message-ID: <20200225171823.GV1148628@redhat.com> (raw)
In-Reply-To: <871rqid35p.fsf@dusky.pond.sub.org>
On Tue, Feb 25, 2020 at 05:48:02PM +0100, Markus Armbruster wrote:
> Max Reitz <mreitz@redhat.com> writes:
>
> > On 15.02.20 15:51, Markus Armbruster wrote:
> >> Review of this patch led to a lengthy QAPI schema design discussion.
> >> Let me try to condense it into a concrete proposal.
> >>
> >> This is about the QAPI schema, and therefore about QMP. The
> >> human-friendly interface is out of scope. Not because it's not
> >> important (it clearly is!), only because we need to *focus* to have a
> >> chance at success.
> >>
> >> I'm going to include a few design options. I'll mark them "Option:".
> >>
> >> The proposed "amend" interface takes a specification of desired state,
> >> and figures out how to get from here to there by itself. LUKS keyslots
> >> are one part of desired state.
> >>
> >> We commonly have eight LUKS keyslots. Each keyslot is either active or
> >> inactive. An active keyslot holds a secret.
> >>
> >> Goal: a QAPI type for specifying desired state of LUKS keyslots.
> >>
> >> Proposal:
> >>
> >> { 'enum': 'LUKSKeyslotState',
> >> 'data': [ 'active', 'inactive' ] }
> >>
> >> { 'struct': 'LUKSKeyslotActive',
> >> 'data': { 'secret': 'str',
> >> '*iter-time': 'int } }
> >>
> >> { 'struct': 'LUKSKeyslotInactive',
> >> 'data': { '*old-secret': 'str' } }
> >>
> >> { 'union': 'LUKSKeyslotAmend',
> >> 'base': { '*keyslot': 'int',
> >> 'state': 'LUKSKeyslotState' }
> >> 'discriminator': 'state',
> >> 'data': { 'active': 'LUKSKeyslotActive',
> >> 'inactive': 'LUKSKeyslotInactive' } }
> >
> > Looks OK to me. The only thing is that @old-secret kind of works as an
> > address, just like @keyslot,
>
> It does.
>
> > so it might also make sense to me to put
> > @keyslot/@old-secret into a union in the base structure.
>
> I'm fine with state-specific extra adressing modes (I better be, I
> proposed them).
>
> I'd also be fine with a single state-independent addressing mode, as
> long as we can come up with sane semantics. Less flexible when adding
> states, but we almost certainly won't.
>
> Let's see how we could merge my two addressing modes into one.
>
> The two are
>
> * active
>
> keyslot old-secret slot(s) selected
> absent N/A one inactive slot if exist, else error
> present N/A the slot given by @keyslot
>
> * inactive
>
> keyslot old-secret slot(s) selected
> absent absent all keyslots
> present absent the slot given by @keyslot
> absent present all active slots holding @old-secret
> present present the slot given by @keyslot, error unless
> it's active holding @old-secret
>
> They conflict:
>
> > (One of the problems that come to mind with that approach is that not
> > specifying either of @old-secret or @keyslot has different meanings for
> > activating/inactivating a keyslot: When activating it, it means “The
> > first unused one”; when deactivating it, it’s just an error because it
> > doesn’t really mean anything.)
> >
> > *shrug*
>
> Note we we don't really care what "inactive, both absent" does. My
> proposed semantics are just the most regular I could find. We can
> therefore resolve the conflict by picking "active, both absent":
>
> keyslot old-secret slot(s) selected
> absent absent one inactive slot if exist, else error
> present absent the slot given by @keyslot
> absent present all active slots holding @old-secret
> present present the slot given by @keyslot, error unless
> it's active holding @old-secret
>
> Changes:
>
> * inactive, both absent: changed; we select "one inactive slot" instead of
> "all slots".
>
> "All slots" is a no-op when the current state has no active keyslots,
> else error.
>
> "One inactive slot" is a no-op when the current state has one, else
> error. Thus, we no-op rather than error in some states.
>
> * active, keyslot absent or present, old-secret present: new; selects
> active slot(s) holding @old-secret, no-op when old-secret == secret,
> else error (no in place update)
>
> Can do. It's differently irregular, and has a few more combinations
> that are basically useless, which I find unappealing. Matter of taste,
> I guess.
>
> Anyone got strong feelings here?
I don't feel like the changes give us any real world benefit, and
especially think deleting one arbitrary slot is just wierd.
IMHO, inactive with both keyslot & old-secret missing should just
be an error condition.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2020-02-25 17:20 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é [this message]
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=20200225171823.GV1148628@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@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).