[systemd-devel] DOSing the TPM to leak the rootfs encryption key

[aplanas]

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.