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