On Fri, 2024-11-29 at 07:36 +0100, Jiri Slaby wrote: > On 28. 11. 24, 17:13, James Bottomley wrote: [...] > > Yes, it tells me the entries in the log for PCR0-7,14 match the log > > entries (for both sha1 and sha256). However there are entries for > > PCR9,12 which don't match. The log shows shim starting at entry > > 32, grub starting at entry 37 and the kernel loading at entry 39 > > the kernel command line logged at 40 to PCR 12, which is > > mismatching. > > > > The next two entries (41,42) are for the mismatching PCR9 and are > > of the initrd and the options and come from the libstub code in the > > kernel early boot (efi-stub-helper.c). > > Note that ovmf logged: > Called TcgDxeHashLogExtendEvent 0 58683000 1B1E78C 5FE63C00 5E3492AA > Data 28 B5 2F FD ... E1 29 FE 0 > > But initrd on disk is 1B1E78B long, not 1B1E78C. So the excessive 0 > at the end above brews the mismatch. See: > https://bugzilla.suse.com/show_bug.cgi?id=1233752#c14 > "By adding the 0 byte I can replicate the measured digest." > > So there is something aligning the initrd. kernel's libstub just uses > and passes load_file2's size down to TcgDxeHashLogExtendEvent, AIUI. > So it'd be sdb, ovmf or something. BTW how are sizes stored > in/fetched from vfat? Well, I was going to explain what EFI does, but it doesn't look relevant now I've had a crash course reading the systemd-boot code. It looks like run() calls image_start() which loads the initrd itself. Then in initrd.c:initrd_prepare() it actually installs its own load file2 protocol which is the protocol the kernel picks up when it loads the initrd. So whatever length the kernel is picking up is, in fact, provided by systemd-boot. I'd suspect something in this double indirection of load file protocols is causing your length mismatch. > But well, fs/fat/ received no significant changes either. We don't use that at all in the EFI stub (and neither does systemd- boot). We use the protocols EFI provides to read fat volumes, so any issue would be in the edk2 (or in your case ovmf) FatPkg. > > This code was last updated in 6.9, so it seems unlikely to have > > suddenly caused a problem. Event 43,44 are exit boot services > > (logged to PCR 5 which matches). line 40 is anomalous: grub is > > supposed to measure the options to the string PCR which should be 8 > > not 12 ... did you patch grub to change this? > > All this is with sdb, not grub, actually. It is? Grub clearly appears in your log in event 37: > SubType 04 File Path > Path Name: \EFI\systemd\grub.efi > Type 7f End of Hardware Device Path But I figured it out: shim is hard coded to look for grub.efi In any case, the entries match what systemd-boot would write (it seems to insist that the string PCR is 12 instead of 8, which explains the log entry). However, this still doesn't explain the mismatch between the log and the PCRs (even if you've got the wrong initrd hash, it should be correctly recorded), but I suspect something updates them later in the boot sequence without adding a log entry. > > The log can't be corrupt because PCR8 is zero, so nothing got > > logged to it. > > > > And do you have the same thing for a working system? > > Let me try. Thanks, that will at least tell me if something booting via systemd is supposed to be able to match log entries on these PCRs (I'm suspecting no is the answer). I'm also trying to set up my own systemd-boot system. James
