[RFCv2 0/9] UEFI emulator for kexec

[Pingfan Liu]

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 at 0pointer.de> wrote:
>
> On Do, 22.08.24 22:29, Pingfan Liu (piliu at redhat.com) 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