This is for after 15.6, but we'll probably add something like this to
our next shim in Ubuntu, so I'd at least like to agree on the correct
way to do this.
Given a set of EFI variables and boot assets, it should be possible
to compute what the value of PCR 7 will be on the next boot.
As shim manages the contents of the SbatLevel variable and this is
measured to PCR 7, export the payloads that shim contains in a new
COFF section (.sbatlevel) so that it can be introspected by code
outside of shim.
The new section works a bit like .vendor_cert - it contains a header
and then the payload. In this case, the header contains no size fields
because the strings are NULL terminated. Shim uses this new section
internally in set_sbat_uefi_variable.
The .sbatlevel section starts with a 4 byte version field which is
not used by shim but may be useful for external auditors if the
format of the section contents change in the future.
This is for after 15.6, but we'll probably add something like this to our next shim in Ubuntu, so I'd at least like to agree on the correct way to do this.
Given a set of EFI variables and boot assets, it should be possible to compute what the value of PCR 7 will be on the next boot.
As shim manages the contents of the SbatLevel variable and this is measured to PCR 7, export the payloads that shim contains in a new COFF section (.sbatlevel) so that it can be introspected by code outside of shim.
The new section works a bit like .vendor_cert - it contains a header and then the payload. In this case, the header contains no size fields because the strings are NULL terminated. Shim uses this new section internally in set_sbat_uefi_variable.
The .sbatlevel section starts with a 4 byte version field which is not used by shim but may be useful for external auditors if the format of the section contents change in the future.