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
This is what EFI Boot Guard is supposed to be. > 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 True. It's always PCR #4 but that doesn't hinder you from measuring the binary to some other and more fitting PCR(s) as well ― matching your use case. > > 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). No, that's not foreseen, but see above. > 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]. Yes, you can measure the binary to PCR #8 as well, then however mashing up the kernel binary and the kernel's cmdline into one PCR. Whether that's sensible or not is the question I asked for referring to the overarching concept you'll want to follow here, i.e., what information / deduction does it give you and what is it you're after (as just measuring is not an end in itself)? > 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) Certainly not :) No need, here it is: - systemd-boot measures kernel command line options to PCR #8: https://github.com/systemd/systemd/blob/main/src/boot/efi/boot.c#L2201 https://github.com/systemd/systemd/blob/main/src/boot/efi/stub.c#L70 - Trusted Grub measures its core to PCR #9 and chain-loadees to PCR #10 https://github.com/Rohde-Schwarz/TrustedGRUB2/blob/master/README.md#13-measurements-in-short - rhboot/grub2 measures Strings to PCR #8 and Binaries to PCR #9 https://github.com/rhboot/grub2/blob/master/include/grub/tpm.h#L23 You surely can find some more but this will give you an idea of how others do it... > > 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. OK, but that ties you to this particular kernel binary (PCR#4) and this particular cmdline (PCR#8). If you now change something, think firmware update, you have to re-seal the secret which is a delicate operation to perform in the context of a firmware update transaction... That said, if you have Secure Boot enabled and use unified kernel images, what does measuring the cmdline to PCR#8 give you in addition to just sealing the secret with ― probably among others ― PCR#4 and thereby bind it to (at least) the unified kernel image ― which includes the cmdline as PE/COFF section? > > > 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. I'm in favor of enabling it unconditionally so that it measures if a TPM is available and fails (gracefully) in case it is not. Kind regards, Christian -- Dr. Christian Storm Siemens AG, Technology, T RDA IOT SES-DE Otto-Hahn-Ring 6, 81739 München, Germany -- 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/20210702135027.woyzrm5j7niy2wcr%40MD1ZFJVC.ad001.siemens.net.
