Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
This is observed on RHEL7 only, RHEL8 has been fixed.
When using "cryptsetup luksFormat" command, the existing key slots are not wiped but just marked "inactive", making it impossible for clevis to bind once all key slots have been used in the past.
This typically happens after reinstalling a system several times.
Example of luksmeta output after reformatting a device:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# luksmeta show -d /dev/vdb
0 active empty
1 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e
2 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e
3 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e
4 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e
5 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e
6 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e
7 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e
# clevis luks bind -f -k - -d /dev/vdb tang '{"url":"http://vm-tang7", "thp":"XXX"}' <<< "XXX"
Error while saving Clevis metadata in LUKS header!
stty: standard input: Inappropriate ioctl for device
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Note that using "cryptsetup luksKillSlot" doesn't help here because the command doesn't work on inactive slots.
This is problematic when reinstalling systems. After a certain number of times, depending on how many Tang servers are used, the system cannot be reinstalled.
Version-Release number of selected component (if applicable):
How reproducible:
Always
Steps to Reproduce: assuming a Tang server is present
1. Format a device
# DEV=/dev/vdb
# PASSWD="temppass"
# cryptsetup luksFormat $DEV -q --force-password <<< "$PASSWD"
2. "clevis luks bind" 7 times to occupy all slots
# for i in $(seq 1 7); do clevis luks bind -f -k - -d $DEV tang '{"url":"http://vm-tang7", "thp":"<some id returned by tang>"}' <<< "$PASSWD"; done
3. Reformat the device
# cryptsetup luksFormat $DEV -q --force-password <<< "$PASSWD"
4. Try to "clevis luks bind" again
# clevis luks bind -f -k - -d $DEV tang '{"url":"http://vm-tang7", "thp":"<some id returned by tang>"}' <<< "$PASSWD"
Actual results:
Error while saving Clevis metadata in LUKS header!
stty: standard input: Inappropriate ioctl for device
Expected results:
Can bind, and key slot 1 used.
Additional info:
The only way I found to wipe the slots is by using "luksmeta wipe" command.
Cryptsetup/libcryptsetup does not manage luksmeta utility additional metadata.
I do not understand what triggers the issue exactly (yet). Is luksmeta unable to say LUKS metadata is different after luksFormat? The keyslots (except one) are inactive, as per this very report. LUKS device uuid is very likely different. Should not luksmeta be able to say something does not add up?
Cryptsetup itself does not wipe other metadata types.
We have added few improvements (in upstream, not in current RHEL7 package) to detect other metadata is present in-before luksFormat operation so that we issue warning to users. If user approves we also wipe previous device signatures detected. Both the detection and wipe is processed via libblkid calls.
Starting with cryptsetup 2.0.6, I think, we wipe the binary keyslot areas before luksFormat. But we do not wipe any other metadata including luksmeta.
That's why I'm curious why this happens. If you overwrite LUKS header with new one, luksmeta utility should be able to detect it and abandon stale metadata related to now deleted LUKS header...
But perhaps the straightforward workaround at this stage of RHEL7 would be to call "luksmeta wipe" after luksFormat in installer?
Newer clevis checks for this situation, where we have stale metadata (inactive slot with clevis UUID associated) and does a wipe itself before saving the new metadata.
Red Hat Enterprise Linux 7.9 was the last minor release scheduled for RHEL 7 and the product entered Maintenance Support 2 Phase, when Red Hat defined Critical and Important impact Security Advisories and selected Urgent Priority Bug Fix Advisories may be released as they become available.
This bugzilla does not seem to meet the inclusion criteria for Maintenance Phase 2, therefore it is closing now, but if you believe that it qualifies for the Maintenance Support 2 Phase, please re-open; otherwise, we recommend moving the request to Red Hat Enterprise Linux 8 if applicable.
Please refer to the Red Hat Enterprise Linux Life Cycle document for more details:
https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase
Description of problem: This is observed on RHEL7 only, RHEL8 has been fixed. When using "cryptsetup luksFormat" command, the existing key slots are not wiped but just marked "inactive", making it impossible for clevis to bind once all key slots have been used in the past. This typically happens after reinstalling a system several times. Example of luksmeta output after reformatting a device: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- # luksmeta show -d /dev/vdb 0 active empty 1 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e 2 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e 3 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e 4 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e 5 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e 6 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e 7 inactive cb6e8904-81ff-40da-a84a-07ab9ab5715e # clevis luks bind -f -k - -d /dev/vdb tang '{"url":"http://vm-tang7", "thp":"XXX"}' <<< "XXX" Error while saving Clevis metadata in LUKS header! stty: standard input: Inappropriate ioctl for device -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Note that using "cryptsetup luksKillSlot" doesn't help here because the command doesn't work on inactive slots. This is problematic when reinstalling systems. After a certain number of times, depending on how many Tang servers are used, the system cannot be reinstalled. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: assuming a Tang server is present 1. Format a device # DEV=/dev/vdb # PASSWD="temppass" # cryptsetup luksFormat $DEV -q --force-password <<< "$PASSWD" 2. "clevis luks bind" 7 times to occupy all slots # for i in $(seq 1 7); do clevis luks bind -f -k - -d $DEV tang '{"url":"http://vm-tang7", "thp":"<some id returned by tang>"}' <<< "$PASSWD"; done 3. Reformat the device # cryptsetup luksFormat $DEV -q --force-password <<< "$PASSWD" 4. Try to "clevis luks bind" again # clevis luks bind -f -k - -d $DEV tang '{"url":"http://vm-tang7", "thp":"<some id returned by tang>"}' <<< "$PASSWD" Actual results: Error while saving Clevis metadata in LUKS header! stty: standard input: Inappropriate ioctl for device Expected results: Can bind, and key slot 1 used. Additional info: The only way I found to wipe the slots is by using "luksmeta wipe" command.