Bug 1731898 - RFE: support for LUKS key management in qemu-img & QMP
Summary: RFE: support for LUKS key management in qemu-img & QMP
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: qemu-kvm
Version: 8.0
Hardware: All
OS: All
Target Milestone: rc
: 8.0
Assignee: Maxim Levitsky
QA Contact: Xueqiang Wei
Depends On:
TreeView+ depends on / blocked
Reported: 2019-07-22 10:56 UTC by Daniel Berrangé
Modified: 2020-05-08 15:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Feature Request
Target Upstream Version:

Attachments (Terms of Use)

Description Daniel Berrangé 2019-07-22 10:56:29 UTC
Description of problem:
The LUKS encryption format supports multiple key slots. This allows multiple distinct passphrases to be used to unlock the same master encryption key. It also allows for replacement of the passphrases, by adding a new one then removing the old one. This is supported in the 'cryptsetup' tool via several key management commands.

When QEMU is being used with a raw LUKS volume, admins can still use the cryptsetup tool to do key management, however, when LUKS is used in qcow2 this is not practical, because the LUKS header will not be in the place that cryptsetup is expecting.

There is thus a need to support key management in the qemu-img command. We need two commands

 - crypto-add-key
   Needs to take an image file path, a key slot number, and the ID of a secret object providing the new passphrase.
   Key slot could be made optional to let us pick a free slot

 - crypto-remove-key

   Needs to take an image file path, and either a key slot number, or the ID of a secret object providing the new passphrase.

   If given a key slot, remove that exact slot
   If given a passphrase, try to unlock each key slot until one succeeds, then remove that one.

   We MUST NOT allow the last key slot to be removed, without explicit confirmation in some way. Perhaps --force option

It is unsafe to use qemu-img on an image used by a running guest, so we also likely need to have QMP + HMP commands which expose the exact same functionality as qemu-img for key slot mgmt.

Comment 2 Ademar Reis 2020-02-05 23:01:16 UTC
QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Comment 3 John Ferlan 2020-02-06 13:54:20 UTC
Still working on coming to an agreement on the API/QMP syntax, most recent posting upstream:


Also see: http://etherpad.corp.redhat.com/luks-api for some recent thoughts

Comment 4 John Ferlan 2020-03-12 11:59:15 UTC
v2 posted upstream: https://lists.nongnu.org/archive/html/qemu-devel/2020-03/msg01838.html

Note You need to log in before you can comment on or make changes to this bug.