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.
Bug 1784524 - Under heavy load (due to many LUKS devices to decrypt), clevis-luks-askpass doesn't decrypt devices
Summary: Under heavy load (due to many LUKS devices to decrypt), clevis-luks-askpass d...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: clevis
Version: 8.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 8.0
Assignee: Sergio Correia
QA Contact: Martin Zelený
Mirek Jahoda
URL:
Whiteboard:
: 1751912 1784084 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-17 16:04 UTC by Renaud Métrich
Modified: 2023-06-26 14:39 UTC (History)
4 users (show)

Fixed In Version: clevis-11-8.el8
Doc Type: Enhancement
Doc Text:
.Clevis now provides improved support for decrypting multiple LUKS devices on boot The `clevis` packages have been updated to provide better support for decrypting multiple LUKS-encrypted devices on boot. Prior to this improvement, the administrator had to perform complicated changes to the system configuration to enable the proper decryption of multiple devices by Clevis on boot. With this release, you can set up the decryption by using the `clevis luks bind` command and updating the initramfs through the `dracut -fv --regenerate-all` command. For more details, see the link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening[Configuring automated unlocking of encrypted volumes using policy-based decryption] section.
Clone Of:
Environment:
Last Closed: 2020-04-28 15:37:11 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Proposed patch to use one clevis-luks-askpass per device (7.91 KB, patch)
2020-01-14 04:03 UTC, Sergio Correia 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-31602 0 None None None 2023-06-26 14:39:46 UTC
Red Hat Product Errata RHEA-2020:1595 0 None None None 2020-04-28 15:37:22 UTC

Description Renaud Métrich 2019-12-17 16:04:18 UTC 
Description of problem:

Booting a VM with many LUKS devices (9 devices, one per file system: / /usr /var /var/log /var/log/audit /tmp /opt /home and swap), clevis-luks-askpass exits after unlocking 1 device only, but systemd doesn't restart it because there is no change in the /run/systemd/ask-password directory.

/ /usr and swap were unlocked in the initramfs phase.
We talk here about unlocking the rest: /var /var/log ...

Currently, with actual code, it's not possible to unlock all these local file systems without modifying heavily the configuration through following Article https://access.redhat.com/articles/4500491
We suppose here that BZ 1784084 was implemented.

Debugging shows the following race condition due to contention on the CPU (my VM has only 2 CPUs, which slows down the boot while setting up LUKS devices):

1. 1 systemd-cryptsetup@ instance sets a path in /run/systemd/ask-password
2. clevis-luks-asspass.service executes "/usr/libexec/clevis-luks-askpass -l"
3. the tool unlocks the device then finds out no other device has to be unlocked, hence starts exiting
4. at that moment other systemd-cryptsetup@ instances set their path in /run/systemd/ask-password
5. due to clevis-luks-asspass.service still being active from systemd's point of view (but currently exiting), systemd doesn't start a new clevis-luks-asspass.service instance later

This leads to a hang of the boot. The only way to un-hang the boot is to "touch /run/systemd/ask-password" directory (done because I had a debug-shell ...).

There is a design issue here: the script /usr/libexec/clevis-luks-askpass should probably run *forever* and get killed by systemd once cryptsetup.target is reached.


Version-Release number of selected component (if applicable):

clevis-11-2.el8.x86_64


How reproducible:

Always on my VM having 2 CPUs and 9 LUKS devices (6 to unlock early after switching root)
Comment 2 Martin Zelený 2020-01-10 13:10:34 UTC 
AC:

System with multiple LUKS encrypted partitions (included /) bound to tang server will boot without need of typing passwords.
Comment 3 Sergio Correia 2020-01-14 04:03:37 UTC 
Created attachment 1652060 [details]
Proposed patch to use one clevis-luks-askpass per device
Comment 6 Sergio Correia 2020-02-13 11:02:42 UTC 
*** Bug 1751912 has been marked as a duplicate of this bug. ***
Comment 7 Sergio Correia 2020-02-13 11:06:37 UTC 
*** Bug 1784084 has been marked as a duplicate of this bug. ***
Comment 9 errata-xmlrpc 2020-04-28 15:37:11 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1595
Note You need to log in before you can comment on or make changes to this bug.