search

squarooticus / efi-measured-boot

Measured Boot for TPM 2.0-enabled UEFI Debian Systems
MIT License
17 stars 2 forks source link

Broken with recent systemd stubs #12

Open squarooticus opened 1 year ago

squarooticus commented 1 year ago

Recent systemd EFI stubs have changed their behavior re: extending PCR 4 in a way that tpm_futurepcr doesn't handle (or at least handle in the naïve way this code leverages it). From an email exchange with Andrei Borzenkov on the systemd mailing list:

However, in v252, the corresponding event occurs earlier in the log and (after some measurements extending PCR 11) is followed by another BSA event extending PCR 4 with a DevicePath I can't parse from a call I can't seem to find in the systemd source code:

  • EventNum: 34 PCRIndex: 4 EventType: EV_EFI_BOOT_SERVICES_APPLICATION DigestCount: 2 Digests:
    • AlgorithmId: sha1 Digest: "9a3c68bb105e4c4e70cbc3375bd45d616e220586"
    • AlgorithmId: sha256 Digest: "36e49f2a0c246db5836b85319e7b2ae04690aca40227895902870a54a054c78b" EventSize: 56 Event: ImageLocationInMemory: 0xb7c36000 ImageLengthInMemory: 7793888 ImageLinkTimeAddress: 0x1000000 LengthOfDevicePath: 24 DevicePath: '04031400f8d1c555cd04b5468a20e56cbb3052d07fff0400'

Can someone help me decode this so I can figure out where this event originates, or (if this event is well-known to the folks working on the trusted computing portion of systemd) tell me where this extension is triggered in the source code? That will at least help me find and hopefully understand the relevant change.

This is media device path type with vendor subtype, vendor GUID is STUB_PAYLOAD_GUID defined and used in src/boot/efi/linux.c.

As a result, I have backed off to using the stub from systemd v247 until I can figure out how to get this working.

squarooticus commented 1 year ago

@grawity may find this one interesting.

squarooticus commented 1 year ago

@grawity: Andrei's comment checks out. It looks like the stub is measuring the kernel blob again, even if it's part of the EFI application that has already been measured by the firmware. Since this is a vendor-specific GUID, I'm guessing there will need to be explicit logic in tpm_futurepcr to simulate this.

This is complicated because the same device path is used no matter where the kernel comes from. For my purposes, it needs to objcopy -O binary --only-section=.linux loader.efi /tmp/kernel_image and measure /tmp/kernel_image because I create loaders with the kernel in the .linux section... but this is hardly universal. It might need to replicate all of the stub's logic for finding the kernel to boot, which seems annoying at best.

grawity commented 1 year ago

I'm actually not sure whether I will continue maintaining tpm_futurepcr at all, as AFAIK systemd-measure is supposed to do the same thing but with better compatibility.

squarooticus commented 1 year ago

In that case, I may maintain my own fork until and unless I decide to switch to systemd's EFI boot implementation. My main interest is in not losing access to remote sites when there's an extended power outage: reliability in booting without intervention is my first priority, the enemy of which is complexity (q.v. systemd).