On Mon, Feb 17, 2020 at 01:28:51PM +0100, Markus Armbruster wrote:
> Kevin Wolf <kw...@redhat.com> writes:
>
> > Am 15.02.2020 um 15:51 hat Markus Armbruster geschrieben:
> >> 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' } }
> >>
> >> LUKSKeyslotAmend specifies desired state for a set of keyslots.
> >
> > Though not arbitrary sets of keyslots, it's only a single keyslot or
> > multiple keyslots containing the same secret. Might be good enough in
> > practice, though it means that you may have to issue multiple amend
> > commands to get to the final state that you really want (even if doing
> > everything at once would be safe).
>
> True. I traded expressiveness for simplicity.
>
> Here's the only practical case I can think of where the lack of
> expressiveness may hurt: replace secrets.
>
> With this interface, you need two operations: activate a free slot with
> the new secret, deactivate the slot(s) with the old secret. There is an
> intermediate state with both secrets active.
>
> A more expressive interface could let you do both in one step. Relevant
> only if the implementation actually provides atomicity. Can it?
This restriction is already present in the the long standing
cryptsetup command, so I don't think it is a big deal. Or to
put it another way I don't see a compelling justification for
why QEMU needs to be special and do it in op.
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 :|
