[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QAPI schema for desired state of LUKS keyslots
From: |
Max Reitz |
Subject: |
Re: QAPI schema for desired state of LUKS keyslots |
Date: |
Tue, 25 Feb 2020 18:00:27 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 |
On 25.02.20 17:48, 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
Oh, I thought that maybe we could use old-secret here, too, for
modifying the iter-time. But if old-secret makes no sense for
to-be-active slots, then there’s little point in putting old-secret in
the base.
(OTOH, specifying old-secret for to-be-active slots does have a sensible
meaning; it’s just that we won’t support changing anything about
already-active slots, except making them inactive. So that might be an
argument for not making it a syntactic error, but just a semantic error.)
[...]
> 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?
The only strong feeling I have is that I absolutely don’t have a strong
feeling about this. :)
As such, I think we should just treat my rambling as such and stick to
your proposal, since we’ve already gathered support for it.
Max
signature.asc
Description: OpenPGP digital signature