On Mo, 10.03.25 11:16, Adrian Vovk (adrianvovk@xxxxxxxxx) wrote: > Hello, > > Just to see if I understand your concern correctly, I'll try boiling it > down to its simplest, by cutting out the need for two partitions. Here's > the scenario: > > - An attacker replaces the real rootfs with a malicious one that just drops > to a shell. The attacker keeps a copy of the original real rootfs > > - The system boots, then tries and fails to decrypt the fake rootfs. > > - The attacker now starts impeding communication between the TPM and the > CPU. Potentially by physically interposing on the bus and blocking > communication. Or by glitching the bus so that the data isn't successfully > measured. Anyway, the attacker somehow makes TPM measurements fail > > - The attacker unlocks their malicious rootfs, and then the system > continues booting. The attacker now gains control of the system via the > root shell. > > - The attacker stops impeding the communication between the TPM and the > CPU. The TPM is still in the same state as it was in the initrd. The > leave-initrd pcrphase, and the PCR15 measurement of the fake root's volume > key, are both missing > > - The attacker is in control of the system, and the TPM is in the right > state to unlock the real rootfs. The attacker talks to the TPM to get the > real rootfs's volume key. Attacker wins > > I think, ultimately, this is the same issue as the one you describe. Do you > think that's correct? > > Lennart would have a better idea than I do of what mitigations to this > would look like. But I suspect that: > > - You can't MITM the TPM, since the communication is encrypted Nope. PCR measurements are not encrypted, at least not by systemd. Lennart -- Lennart Poettering, Berlin