[RFCv2 0/9] UEFI emulator for kexec

[Lennart Poettering]

On Mo, 09.09.24 21:38, Pingfan Liu (piliu at redhat.com) wrote:

> 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.

I's a set of PCR values pcrlock predicts, one or more for each PCR. It
then compiles a TPM "policy" from that, which is identified by a hash,
and that hash is then stored in a TPM "nvindex" (which is a bit of
memory a tpm provides).

> One thing should be noticed is that PCR value can not be affected.

Well, a kexec *should* affect some PCRs. Replacement of the kernel
*must* be visible in the measurement logs somehow, in a predictable
fashion.

> 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.

Well, it's not systemd that checks that, but the TPM. i.e. not the
untrusted OS but the the suppedly more trusted TPM.

So, key is that we want that measurements take place, the kexec
operation *must* be made visible in the measurement logs. But it must
be in a well-defined way, and ideally as an extension of the
measurements sd-stub currently makes.

(BTW, I personally don't think emulating EFI is really that
important. As long as we get the key functionality that sd-stub
provides also when doing kexec I am happy. i.e. whether it is sd-stub
that does this or some other piece of code doesn't really matter to
me. What I do care about is that we can parameterize the invoked
kernel in a similar fashion as we can parameterize sd-stub, and that
the measurements applied are also equivalent.)

Lennart

--
Lennart Poettering, Berlin