sd-boot: handle switch from UKI to split kernel/initrd

[okirch]

At the moment, PCR prediction in pcr-oracle relies on the sequence of events in the UEFI eventlog to always be the same. pcr-oracle will just re-compute a new hash for each event, taking into account the system's current state.

On machines that use systemd-boot, it's possible that users might switch from booting a split kernel/initrd/options to a unified kernel image (UKI). These two scenarios generate a different sequence of events, meaning pcr-oracle will not be able to predict a correct set of PCR values.

The simple approach would be to document that and tell the user that switching between a split kernel and a UKI means they have to reboot, supply the recovery pass phrase to unlock their root partition, and then re-run pcr-oracle (or whatever shell script would be used to wrap the whole thing).

A more complex approach would be a major revision to the mode of operation of pcr-oracle, and I'm not looking forward to that :-)

[okirch]

@aplanas @lcp I'd appreciate your thoughts on this topic :-)

[aplanas]

users might switch from booting a split kernel/initrd/options to a unified kernel image (UKI). These two scenarios generate a different sequence of events, meaning pcr-oracle will not be able to predict a correct set of PCR values.

I think that this can be predicted. The changes will be:

• PCR#4
  • SPLIT: The kernel is measured
  • UKI: The UKI is measured
• PCR#9
  • SPLIT: cmdline and initrd are measured, the device path is used to differentiate them
  • UKI: Nothing is measured (not 100% sure, I need to check the stub code and see how initrd is prepared)
  • PCR#12
  • SPLIT: Nothins is measured
  • UKI: The different UKI sections are measured in a predicted order

pcr-oracle can detect when the user is moving from one system to another (the current boot entry is stored in a EFI variable, and the cmdline is pointing to an initrd, and the next boot entry can be detected via sorting them with vercmp already in pcr-oracle). If this is the case the will be easy to understand the PCR#4 event order will not change (but will measure the UKI instead the kernel), the PCR#9 will pbly not be extended, and PCR#12 will have a predictable sequence of event.

This last point of PCR#12 is the reason why systemd choose a different PCR number for itself: to simplify the prediction. Since several versions systemd-measure is already generating the expected TPM2 policy in JSON format.