Merge pull request #324 from chrisccoulson/preinstall-add-check-pcr4

preinstall: Add checks for PCR4.

This adds checks some checks for PCR4.

The caller supplies a context.Context to which an EFI variable backend
is attached, a internal_efi.HostEnvironment implementation, a TCG log, a
PCR digest algorithm (the optimum for this is computed earlier by
another function that does a more general check of the TCG log) and a
list of boot images related to the current boot. These are used to
verify the digests in the EV_EFI_BOOT_SERVICES_APPLICATION events.

It reads the BootCurrent EFI variable and matches this to the
EFI_LOAD_OPTION associated with the current boot from the TCG log - it
uses the log as BootXXXX EFI variables can updated at runtime and might
be out of date when this code runs.

In the pre-OS environment, it checks that the log only contains either
a single EV_OMIT_BOOT_DEVICE_EVENTS event or a single EV_EFI_ACTION
"Calling EFI Application from Boot Option" event (after which, it expects
to see the EV_SEPARATOR event to signal the transition to OS-present). It
also permits EV_EFI_BOOT_SERVICES_APPLICATION events in the pre-OS
environment if the BootOptionSupport EFI variable indicates that system
preparation applications are supported, although these must be before the
previously mentioned EV_EFI_ACTION event. The profile generating code in
efi/fw_load_handler.go copies these pre-OS events (including sysprep
applications to the final policy).

Note that firmware that implements v1.06 of the TCG PC-Client PFP spec
implements another EV_EFI_ACTION event that indicates the number of the
Boot option that the load occurred from - this code will need to include
support for that quite soon. There is a corresponding github issue for
this (#308).

When processing the initial part of the OS-present section of the log,
it expects to find the EV_EFI_BOOT_SERVICES_APPLICATION for the initial
boot loader (IBL), and it expects the path of this to match the previously
discovered load option associated with the current boot - note that it
doesn't expect a complete match. See how path matching works in
efi.DevicePath.Matches. Any other event type at this stage is rejected as
an error, as it would result in an invalid policy being generated by the
code in efi/fw_load_handler.go. If the first EV_EFI_BOOT_SERVICES_APPLICATION
event is not the IBL, it checks to see if it is part of Absolute, in which
case it skips it and looks for the next event. Note that Absolute will be
copied to the computed policy by efi/fw_load_handler.go, if it is present,
although it's recommended that this is disabled instead. The next event
must be the IBL, else an error is returned. It verifies that the digest in
the log matches the Authenticode digest of the first boot file supplied to
the function.

It then continues to process EV_EFI_BOOT_SERVICE_APPLICATION events in
the log (permitting, but ignoring other event types - it's expected that
if other OS boot code uses other event types in the log, the policy
generation code for that OS component in the secboot efi package emits
these. For each launch event (EV_EFI_BOOT_SERVICES_APPLICATION), it
verifies that the digest in the log matches the Authenticode digest of
the next boot file supplied. Note that it is not mandatory to verify every
one of these events, so it's not mandatory to supply every boot
component to the function.

Some OS components may not rely on the boot services LoadImage API for
loading subsequent stages (eg, shim). For the
EV_EFI_BOOT_SERVICES_APPLICATION digests to be correct, these components
rely on the existence of the EFI_TCG2_PROTOCOL with the PE_COFF_IMAGE
flag. There isn't a direct way to test for this, so for this reason, the
function does have to verify the digest of the
EV_EFI_BOOT_SERVICES_APPLICATION event associated with the secondary
boot loader (SBL), if there is one. This image must be supplied to this
function, else an error will be returned.

On success, the function will return a set of flags indicating whether
system preparation applications were detected to be running, whether
Absolute was detected to be running, or whether it wasn't able to verify
all EV_EFI_BOOT_SERVICES_APPLICATION event digests because not all paths
to every component for the current boot were supplied. What happens with
these flags will be customizable with flags supplied to the higher level
RunChecks API.