.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.
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)
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