On 2025-03-14 08:26, Andrei Borzenkov wrote:
I would like to see a solution that can be enabled by default for an
average non-technical user. Both your solution and upstream PR
effectively lock users out if something goes wrong. This may be
appropriate for a standalone appliance, but for a common desktop
installation I want to prevent automatic decryption, not to block the
user from accessing his system to repair it.
You can use "measure-pcr-validator.ignore=true" in the cmdline to
continue the boot.
This will invalidate the policy and the password will be asked. You can
then debug the issue, enter the PIN to update the policy if required, or
recalculate the PCR15 file and sign it (both done by the same command)
Right, PCR15 will be changed just when the device is unlocked, but
again, the problem is that there is no order in PCR15 extension. If
you
create a policy that adds PCR15 expecting 0x0...0 to unlock root, then
this can work, or not. If you have an encrypted swap, then the value
of
PCR15 is not determined unless you impose an order.
Exactly the same consideration applies to your suggested solution.
That is why there is a generator to fix this.
I personally find this generator ugly, and based on systemd-verifyfs
there is the possibility to avoid it adding a new crypttab parameter
(tpm2-measure-pcr-value=0xX...X). If sd-cryptsetup ask to a quote, it
can validate the event log and find the expected value in it, without
consideration of the order.
So technically if systemd gains a quote function, validating the
integrity of the device would not require to order systemd-cryptsetup.
