Re: QAPI schema for desired state of LUKS keyslots

[Eric Blake <eblake@redhat.com>]

On 2/17/20 6:28 AM, Markus Armbruster wrote:

>>> 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?

Or put another way, can atomicity be added via 'transaction' later?  If 
so, reusing one common interface to provide atomicity is nicer than 
making every interface reimplement atomicity on an ad hoc basis.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org