sd-stub: measure sysext images picked up by sd-stub into PCR 13

Let's grab another so far unused PCR, and measure all sysext images into
it that we load from the ESP. Note that this is possibly partly redundant,
since sysext images should have dm-verity enabled, and that is hooked up
to IMA. However, measuring this explicitly has the benefit that we can
measure filenames too, easily, and that all without need for IMA or
anything like that.

This means: when booting a unified sd-stub kernel through sd-boot we'll
now have:

1. PCR 11: unified kernel image payload (i.e. kernel, initrd, boot
   splash, dtb, osrelease)

2. PCR 12: kernel command line (i.e. the one embedded in the image, plus
   optionally an overriden one) + any credential files picked up by
   sd-stub

3. PCR 13: sysext images picked up by sd-stub

And each of these three PCRs should carry just the above, and start from
zero, thus be pre-calculatable.

Thus, all components and parameters of the OS boot process (i.e.
everything after the boot loader) is now nicely pre-calculable.

NOTE: this actually replaces previous measuring of the syext images into
PCR 4. I added this back in 845707aae23b3129db635604edb95c4048a5922a,
following the train of thought, that sysext images for the initrd should
be measured like the initrd itself they are for, and according to my
thinking that would be a unified kernel which is measured by firmware
into PCR 4 like any other UEFI executables.

However, I think we should depart from that idea. First and foremost
that makes it harder to pre-calculate PCR 4 (since we actually measured
quite incompatible records to the TPM event log), but also I think
there's great value in being able to write policies that bind to the
used sysexts independently of the earlier boot chain (i.e. shim, boot
loader, unified kernel), hence a separate PCR makes more sense.

Strictly speaking, this is a compatibility break, but I think one we can
get away with, simply because the initrd sysext images are currently not
picked up by systemd-sysext yet in the initrd, and because of that we
can be reasonably sure noone uses this yet, and hence relies on the PCR
register used. Hence, let's clean this up before people actually do
start relying on this.

0 files changed, 0 insertions, 0 deletions