[Top][All Lists]

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

Re: QAPI schema for desired state of LUKS keyslots

From: Eric Blake
Subject: Re: QAPI schema for desired state of LUKS keyslots
Date: Mon, 17 Feb 2020 06:44:34 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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


     { '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

reply via email to

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