On Di, 11.03.25 13:16, Lennart Poettering (lennart@xxxxxxxxxxxxxx) wrote: > On Mo, 10.03.25 12:27, Adrian Vovk (adrianvovk@xxxxxxxxx) wrote: > > > Well, the TPM is supposed to be secure against hardware debugger access, in > > theory. Ditto with CPUs, and JTAG lockout. > > > > So if there's TOCTOU bugs in our code we need to be robust against them too. > > > > Anyway, I don't think this is a TOCTOU bug. Basically, it seems that we're > > sometimes OK letting communication to the TPM fail. In which case, an > > attacker can cause the communication to fail, and we'll be none the wiser > > > > If device specific encryption key leaks, then the data there can be modified > > > > by the attacker. I too fail to see the bug here. > > > > > > > Right, this is what we're trying to avoid. > > > > Basically, the bug is: an attacker does a DOS on the TPM in such a way that > > systemd boots to the rootfs without measuring the `leave-initrd` pcrphase, > > or the fake rootfs's pcr15. Once in the rootfs, the TPM doesn't know that > > it has left the initrd. And that's game over: the attacker stops DOSing the > > TPM, and extracts the encryption keys for the real rootfs from the TPM. > > it is true that we currently do not block continued booting if a > measurement fails. > > I figure systemd-pcrextend should start to simply invoke > reboot(RB_HALT_SYSTEM) if a TPM exists but it cannot extend a > PCR. Happy to take a PR for that. I prepped a PR for that now: https://github.com/systemd/systemd/pull/36705 Turned out to be much simpler than I expected... Lennart -- Lennart Poettering, Berlin