[systemd-devel] Trying to understand change in PCR 4 extension behavior

[Kyle Rose]

On Fri, Dec 30, 2022 at 9:31 AM Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> > Do you know what the reasoning is behind re-extending PCR 4 with a
> > kernel measurement here? Would it not have already been measured as
> > part of the EFI blob and incorporated into PCR 4 by the firmware
> > before the stub was launched?
>
> It is not systemd. The difference between v247 and v252 is in how kernel
> is started. v247 called into linux kernel directly while v252 goes via
> LoadImage protocol which calls into firmware. So it could be your
> firmware logging loaded image.

Interesting. Good to know. It's very likely the firmware measures
whatever it's told to load, under the assumption that it hasn't been
previously measured.

> > For context, the previous behavior was ideal for purposes of
> > predicting future PCR measurements because all of the necessary
> > information could be derived directly from the TPM event log; with the
>
> You still gets all necessary information from TPM even log, not?

How so? I don't know what was loaded without knowing the behavior of the stub.

With v247, the TPM event log had only one BSA event, and that event
contained the path of the EFI loader. Thus, upon updating the EFI
loader, the PCR prediction logic would encounter this BSA event and
measure the new loader instead of the old one, producing a set of PCRs
for the next boot.

With v252, the PCR prediction logic somehow needs to know that the BSA
event for device path
"04031400f8d1c555cd04b5468a20e56cbb3052d07fff0400" refers to the
kernel image embedded in the loader, and then `objcopy -O binary ...`
the .linux section and measure that. And that behavior could change in
the future without warning.

Does this clear up the difficulty here? If the device path could not
be an opaque value but instead indicate what exactly is being
measured, that would make this mechanism more general and more
extensible.

Thanks,
Kyle