qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QAPI schema for desired state of LUKS keyslots


From: Daniel P . Berrangé
Subject: Re: QAPI schema for desired state of LUKS keyslots
Date: Tue, 25 Feb 2020 17:18:23 +0000
User-agent: Mutt/1.13.3 (2020-01-12)

On Tue, Feb 25, 2020 at 05:48:02PM +0100, Markus Armbruster wrote:
> Max Reitz <address@hidden> 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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]