Slow unlock and passphrase request remains during boot

[kowalski7cc]

OS: Fedora 31
RPMs: clevis-11-10.fc31.x86_64 manually installed
(The issue is the same as 11-8 from dnf)
After a normal installation sudo clevis luks bind tpm2 ... and sudo dracut -f unlock happens automatically as expected. But before unlocking happens it take almost 2-3s (On an i7 - NVMe SSD, so it's not performance issue). Also after disk unlock, passphrase request isn't dismissed and remains during boot or upgrade reboot (During updates install remains the passphrase request and under is written the update progress).
One time, I don't know how, I got it to unlock almost istantly and with passphrase request dismissal.

[kowalski7cc]

It seems that during a reboot it's faster and passphrase request is dismissed correctly. Maybe something with PCRs? I use these PCRs: 0,1,2,3,4,5,6,7
Full command:
sudo clevis luks bind -d /dev/nvme0n1p3 tpm2 '{"pcr_ids":"0,1,2,3,4,5,6,7"}'
This time I reinstalled a clean os and clevis-11-10.fc31.x86_64 from repositories

[kowalski7cc]

I'm also using LUKS2 as shown in cryptsetup

        Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2i
	Time cost:  5

[sergio-correia]

Also after disk unlock, passphrase request isn't dismissed and remains during boot or upgrade reboot (During updates install remains the passphrase request and under is written the update progress).

When this happens, the passphrase request isn't dismissed at all? What do you mean when you say upgrade reboot? And How often does this happen? Can you reproduce it reliably? Also, how many devices are you trying to unlock?

[kowalski7cc]

Yes, the passphrase request isn't dismissed at all during the plymouth boot animation.
Sometimes during reboots it's dismissed and it takes just some seconds to unlock.
I can see if i press esc that during the boot that in this stage it takes much time before continuing automatically:

[DominiqueDevinci]

Hello @kowalski7cc ,
about the decryption time you have already see my issue.
About passphrase i found a way to disable it. In fact systemd already avoid to ask the password if a keyfile is provided in kernel option (for instance), and it should be ideally awesome to add an option to disable password prompting (https://github.com/systemd/systemd/blob/master/src/cryptsetup/cryptsetup.c line 861).

But for now, you have an easy way to disable the forwarding of password prompt like this:

mkdir -p /usr/lib/systemd/system/blacklisted/
mv "/usr/lib/systemd/system/systemd-ask-pass"* /usr/lib/systemd/system/th_blacklisted/

or just
rm "/usr/lib/systemd/system/systemd-ask-pass"*

and don't forget to update your initramfs (dracut -f for instance).

Regards,
Dominique.

[kowalski7cc]

@DominiqueDevinci I think deleting/blacklistong systemd-ask-pass isn't a solution, if a PCR changes wouldn't you be locked? Or would not be showed in the playmouth animation?
Also what you mean about probiding a keyfile? I'm just using TPM authenticator.

[DominiqueDevinci]

Hello @kowalski7cc i agree that it's a savage solution, but it suits to my case where nobody know the passphrases, and where the computer must be definitely locked in case of compromise. Of course i understand it's not a good solution for everyone, but if you really want to disable this message it works (you can also modify these services to be more flexible instead or deleting them, for instance prompt the password after X seconds if the partition is still locked or if a failed decryption is detected).

About keyfile I said:

In fact systemd already avoid to ask the password if a keyfile is provided in kernel option (for instance), and it should be ideally awesome to add an option to disable password prompting

I was speaking about this file line 860 : https://github.com/systemd/systemd/blob/master/src/cryptsetup/cryptsetup.c#L860

if (!key_file && !arg_pkcs11_uri) {
                                r = get_password(argv[2], argv[3], until, tries == 0 && !arg_verify, &passwords);

You can see that systemd doesn't ask for password when it sees that a keyfile or a pkcs11 protocol is used. And I said systemd should also doesn't prompt the password when clevis is used (leveraging a kernel argument typically). so i think the right solution is a patch of systemd taking in account an argument which can disable this prompt (generic argument or clevis specific argument, the discussion is open about that ... ).

Without this patch in systemd i fear that our possibilities on clevis side are limited to modifying the services systemd-ask-pass*

Cheers,
Dominique.

[kowalski7cc]

But I don't get why it sometimes (rarely) works as expected, dismissing the password request

[grigorig]

This bug is literally years old. This is very confusing behavior - I initially thought the Clevis unlocker didn't work at all. Any news?

[sergio-correia]

I opened this issue with plymouth a while ago about it not dismissing the splash screen when a LUKS device is unlocked non-interactively (e.g. by clevis), but it's still open: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/126

[arthurlt]

I'm seeing the same issue on my fresh Fedora 37 install. Definitely had me on a wild goose chase trying to figure out if there was an issue with my TPM or if I ran through the steps incorrectly.

At the very least a warning on the README would be nice.

Like @ArturGaspar's PR is there a way to have clevis succeed or fail before asking plymouth for password? That would side-step the plymouth bug.

[krumelmonster]

Very confusing indeed. My workaround for a computer I'll hand to someone else is for now to disable splash and quiet kernel parameters so the prompt is buried under the boot messages. Should clevis fail to decrypt though (PCR change) the prompt will stay visible and functional for entering a passphrase.