Description of problem: When binding a TPM2 to a LUKS encrypted lvm, the token/key is written into an inactive slot. Version-Release number of selected component (if applicable): clevis-luks-11-4.fc29.x86_64 How reproducible: Steps to Reproduce: 1. sudo clevis luks bind -d /dev/sda3 tpm2 '{"pcr_ids":"7"}' 2. sudo luksmeta show -d /dev/sda3 3. Actual results: 0 active empty 1 active empty 2 inactive xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 3 inactive empty 4 inactive empty 5 inactive empty 6 inactive empty 7 inactive empty Expected results: 0 active empty 1 active xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 2 inactive empty 3 inactive empty 4 inactive empty 5 inactive empty 6 inactive empty 7 inactive empty Additional info:
I think the problem is actually in luksmeta. cf. Bug 1676898
Please cf. Chapter 6.6 of the RedHat 8 Beta Documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/configuring_and_managing_security/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_configuring-and-managing-security#configuring-manual-enrollment-of-root-volumes-using-clevis_configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption
(In reply to Dahlhoff from comment #0) > Description of problem: > When binding a TPM2 to a LUKS encrypted lvm, the token/key is written into > an inactive slot. > > Version-Release number of selected component (if applicable): > clevis-luks-11-4.fc29.x86_64 > > How reproducible: > > Steps to Reproduce: > 1. sudo clevis luks bind -d /dev/sda3 tpm2 '{"pcr_ids":"7"}' > 2. sudo luksmeta show -d /dev/sda3 > 3. > Hi, a few questions: 1) Can you still reproduce it? If so, could you please double check the steps to reproduce? 2) When binding, do you provide the correct LUKS password? I get the "inactive xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" situation when I do not provide the correct password; otherwise, it seems to work as expected. 3) Do you get any error messages after binding like "Error while saving Clevis metadata in LUKSMeta!", or does it seem to succeed?
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
(In reply to Sergio Correia from comment #4) > (In reply to Dahlhoff from comment #0) > > Description of problem: > > When binding a TPM2 to a LUKS encrypted lvm, the token/key is written into > > an inactive slot. > > > > Version-Release number of selected component (if applicable): > > clevis-luks-11-4.fc29.x86_64 > > > > How reproducible: > > > > Steps to Reproduce: > > 1. sudo clevis luks bind -d /dev/sda3 tpm2 '{"pcr_ids":"7"}' > > 2. sudo luksmeta show -d /dev/sda3 > > 3. > > > > Hi, a few questions: > 1) Can you still reproduce it? If so, could you please double check the > steps to reproduce? > 2) When binding, do you provide the correct LUKS password? I get the > "inactive xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" situation when I do not > provide the correct password; otherwise, it seems to work as expected. > 3) Do you get any error messages after binding like "Error while saving > Clevis metadata in LUKSMeta!", or does it seem to succeed? Hi there, I tested this again on Fedora 31 - still the same bug. [root@localhost ~]# uname -a Linux localhost 5.3.11-300.fc31.x86_64 #1 SMP Tue Nov 12 19:08:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# cryptsetup luksFormat --type=luks1 /dev/sdb1 WARNING! ======== Hiermit werden die Daten auf »/dev/sdb1« unwiderruflich überschrieben. Are you sure? (Type uppercase yes): YES Geben Sie die Passphrase für »/dev/sdb1« ein: Passphrase bestätigen: [root@localhost ~]# clevis luks bind -d /dev/sdb1 tpm2 '{"pcr_ids":"7"}' You are about to initialize a LUKS device for metadata storage. Attempting to initialize it may result in data loss if data was already written into the LUKS header gap in a different format. A backup is advised before initialization is performed. Do you wish to initialize /dev/sdb1? [yn] y Enter existing LUKS password: 2 [root@localhost ~]# luksmeta show -d /dev/sdb1 0 active empty 1 active empty 2 inactive ********-****-****-****-************ 3 inactive empty 4 inactive empty 5 inactive empty 6 inactive empty 7 inactive empty
Ps: > 1) Can you still reproduce it? If so, could you please double check the > steps to reproduce? Yes, see my last response. > 2) When binding, do you provide the correct LUKS password? I get the > "inactive xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" situation when I do not > provide the correct password; otherwise, it seems to work as expected. Well, that should not happen either, right? > 3) Do you get any error messages after binding like "Error while saving > Clevis metadata in LUKSMeta!", or does it seem to succeed? Succeeds
(In reply to Dahlhoff from comment #7) > Ps: > > > 1) Can you still reproduce it? If so, could you please double check the > > steps to reproduce? > > Yes, see my last response. > > > 2) When binding, do you provide the correct LUKS password? I get the > > "inactive xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" situation when I do not > > provide the correct password; otherwise, it seems to work as expected. > > Well, that should not happen either, right? > Right. I was trying to understand if that was the the only issue here. I have a fix in the works for this one and should submit a PR upstream in the next days. > > 3) Do you get any error messages after binding like "Error while saving > > Clevis metadata in LUKSMeta!", or does it seem to succeed? > > Succeeds Thanks for testing.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopening this, as it is still an issue in Fedora 31.
FEDORA-2019-4f9bba54b5 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4f9bba54b5
FEDORA-2019-ef9798d154 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ef9798d154
clevis-11-6.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ef9798d154
clevis-11-11.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4f9bba54b5
clevis-11-6.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
clevis-11-11.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.