Hi Lennart, I spent some time understanding the systemd-pcrlock and TPM stuff, and got some idea about it. Could you correct me if I'm wrong? Please see the following comments inlined. On Mon, Aug 26, 2024 at 9:40 PM Lennart Poettering <mzxreary@xxxxxxxxxxx> wrote: > > On Do, 22.08.24 22:29, Pingfan Liu (piliu@xxxxxxxxxx) wrote: > > > > Hmm, I'd really think about this with some priority. The measurement > > > stuff should not be an afterthought, it typically has major > > > implications on how you design your transitions, because measurements > > > of some component always need to happen *before* you pass control to > > > it, otherwise they are pointless. > > > > > > > At present, my emulator returns false to is_efi_secure_boot(), so > > systemd-stub does not care about the measurement, and moves on. > > > > Could you enlighten me about how systemd utilizes the measurement? I > > grepped 'TPM2_PCR_KERNEL_CONFIG', and saw the systemd-stub asks to > > extend PCR. But where is the value checked? I guess the systemd will > > hang if the check fails. > > systemd's "systemd-pcrlock" tool will look for measurements like that > and generate disk encryption TPM policies from that. > Before kexec reboots to the new kernel systemd-pcrlock can predict the expected PCR value and store it in the file system. One thing should be noticed is that PCR value can not be affected. And kexec rebooting happens. systemd-stub extends the PCR value. When the system is up, systemd checks the real PCR value against the expected value rendered by systemd-pcrlock? If matching, all related policies succeed. Do I understand correctly? Thanks, Pingfan
