Hi Christian
On 7/1/2021 9:02 PM, Christian Storm wrote:
Hi Cedric,
Make use of systemd code to measure the kernel command line for the
selected configuration into PCR#8. This also causes the firmware
to add the measurement for the loaded EFI image into PCR#4 (as per
UEFI specs). With this change both the loaded kernel and command
line options are measured.
Measurement to PCR #4 is done by the EFI firmware for each LoadImage()'d
EFI binary. According to the spec, "UEFI Boot Manager Code (usually the
MBR) and Boot Attempts" is supposed to be measured to PCR #4.
Correct. More specifically, the target PCR is selected as follows:
EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION => 4
EFI_IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER => 2
EFI_IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER => 2
The type of the image is encoded into the PE/COFF header
Now, an
OS kernel doesn't exactly qualify for this semantically, right?
Correct but LoadImage() does not seem to provide a mean to select a PCR
Probably, PCRs #8 - #15 "Defined for use by the Static OS" (according to
the spec) are a better match for measuring the OS kernel, additionally.
You're measuring the kernel command line to this range already.
This would have been my preference as well but again LoadImage() isn't
giving an option to select a different PCR (unless I missed it). What we
could do is side-load the UEFI image and HashLogExtend it ourselves to
PCR[8] but LoadImage would still be needed and would also measure it and
extend PCR[4]. I'll check again what other boot-loaders do (we may not
be the only ones load a Linux kernel image packaged as an EFI binary)
That said, what's the overarching concept behind this? Just measuring
"something" is not an end in itself. How is that supposed to be sensibly
used (e.g., by the OS) to actually leverage the measurements? According
to this answer, the measurement(s) should be performed by EFI Boot Guard
to support the intended idea/concept.
We are wanting to get boot artifacts measured so we can locally attest
that we have booted into a well-known system and may safely unseal a
secret sealed into the TPM. Our secret would be sealed with at least
PCR[4] and PCR[8]. In our case, we don't really need to say which
element was tampered, we just want to prevent the bad guy from reading
our secret.
As it is now, you have to poke and replay PCR #4 to assess the OS kernel
as the OS kernel and the bootloader are mashed up in PCR #4. Otherwise,
you can just tell that *some* OS kernel has been booted with the same or
different kernel command lines (via PCR #8).
Only if your goal is to provide full attestation and needing to provide
details and what was tampered.
Use of the TPM may be disabled by passing --disable-tpm to the
configure script.
Why this distinction? It doesn't harm to have it enabled unconditionally
with measurement simply failing in case no TPM is available, does it?
What is the reasoning behind making in compile-time conditional?
I would be happy to remove this and all the #ifdef ENABLE_TPM. I was
just worried that some people may not want this code enabled/built even
though I see no harm in always having it.
Kind regards,
Christian
--
You received this message because you are subscribed to the Google Groups "EFI Boot
Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/efibootguard-dev/628986cd-6241-8cef-c82a-7bd3d0a4e691%40mentor.com.
