Bugzilla – Bug 1222183
pcr-oracle fails to parse LOADER_CONF_EVENT_TAG_ID
Last modified: 2024-07-01 14:54:43 UTC
I believe on March, 26 I attempted to update MicroOS instance. Update failed, but more importantly it also stopped generating the correct predictions. As far as I can tell, attempted update managed to install newer version of systemd-boot which started to add TPM2 event entry that pcr-oracle fails to parse. 10:~ # /tmp/sdbootutil update-predictions ::: Initializing predictor for sha256:0,2,4,7,9 from eventlog ::: Detected TPMv2 event log ::: Successfully read 46 events from TPM event log ::: Created new predictor ::: runtime_read_efi_application(/dev/vda2, /EFI/systemd/shim.efi) ::: Reading EFI application (/dev/vda2)/EFI/systemd/shim.efi ::: runtime_read_efi_application(/dev/vda2, /EFI/systemd/grub.efi) ::: Reading EFI application (/dev/vda2)/EFI/systemd/grub.efi Error: Unable to parse EVENT_EVENT_TAG event from TPM log ::: 04f9c: event type=EVENT_EVENT_TAG pcr=5 digests=4 data=32 bytes ::: sha1 01d4e1ca16f118f6fcd954e175c0116c4a4f746b ::: sha256 bdbea6dbc6791de89a483abc3a61af8e910249e7565682ff2011c910a490520a ::: sha384 12ebd339e16a134b0aeeb3114bd5b233f9f862037b7550c922a7c73686fa616995273aa75144640d4fb911945d7b5f55 ::: sha512 7c4a18a73955640cde19777b87735f1ca928fe6ef6b54aa3a6d8117c8eaadbd6c00778165a9a320303644489c242c88a5b2ca6b20be1ffe75f70d5b930f647f6 ::: Data: ::: 0000 2a 58 bc f5 18 00 00 00 6c 00 6f 00 61 00 64 00 65 00 72 00 2e 00 63 00 6f 00 6e 00 66 00 00 00 *X......l.o.a.d.e.r...c.o.n.f... Fatal: Aborting. Error: Failed to install TPM predictions for From systemd sources src/fundamental/tpm2-pcr.h:#define LOADER_CONF_EVENT_TAG_ID UINT32_C(0xf5bc582a) loader.conf existed for a long time. Bootloader was updated at this day. 10:~ # ls -l /boot/efi/loader total 32 drwxr-xr-x. 2 root root 8192 Feb 23 14:58 entries -rwxr-xr-x. 1 root root 6 Dec 26 21:28 entries.srel -rwxr-xr-x. 1 root root 41 Dec 26 21:28 loader.conf -rwxr-xr-x. 1 root root 32 Mar 30 18:26 random-seed 10:~ # efibootmgr BootCurrent: 0007 Timeout: 3 seconds BootOrder: 0007,0000,0001,0002,0003,0004,0005,0006 Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331) Boot0001* UEFI Misc Device PciRoot(0x0)/Pci(0x2,0x0){auto_created_boot_option} Boot0002* UEFI PXEv4 (MAC:525400123456) PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,1)/IPv4(0.0.0.00.0.0.0,0,0){auto_created_boot_option} Boot0003* UEFI PXEv6 (MAC:525400123456) PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,1)/IPv6([::]:<->[::]:,0,0){auto_created_boot_option} Boot0004* UEFI HTTPv4 (MAC:525400123456) PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,1)/IPv4(0.0.0.00.0.0.0,0,0)/Uri(){auto_created_boot_option} Boot0005* UEFI HTTPv6 (MAC:525400123456) PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,1)/IPv6([::]:<->[::]:,0,0)/Uri(){auto_created_boot_option} Boot0006* EFI Internal Shell FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1) Boot0007* openSUSE Boot Manager HD(2,GPT,4d904b6d-6495-4891-8481-fe0fbdacec21,0x1800,0xfa000)/File(\EFI\systemd\shim.efi) 10:~ # ls -l /boot/efi/EFI/systemd total 1880 -rwxr-xr-x. 1 root root 846096 Mar 28 21:11 MokManager.efi -rwxr-xr-x. 1 root root 62 Mar 28 21:11 boot.csv -rwxr-xr-x. 1 root root 98160 Mar 28 21:11 grub.efi -rwxr-xr-x. 1 root root 17 Mar 28 21:11 installed_by_sdbootutil -rwxr-xr-x. 1 root root 934024 Mar 28 21:11 shim.efi -rwxr-xr-x. 1 root root 451 Mar 17 07:57 tpm2-pcr-public-key.pem -rwxr-xr-x. 1 root root 631 Mar 17 07:57 tpm2-pcr-signature.json 10:~ # Apart from the obvious bug in pcr-oracle, this invalidates any claim of "immutability" of MicroOS - failed update makes it impossible to boot MicroOS without human intervention. 10:~ # ls -l /boot/efi/EFI/systemd/grub.efi -rwxr-xr-x. 1 root root 98160 Mar 28 21:11 /boot/efi/EFI/systemd/grub.efi 10:~ # ls -l /usr/lib/systemd/boot/efi/systemd-bootx64.efi -rw-r--r--. 1 root root 94576 Feb 21 22:42 /usr/lib/systemd/boot/efi/systemd-bootx64.efi 10:~ #
(In reply to Andrei Borzenkov from comment #0) Hi Andrei, thanks a lot for the detailed bug report > Error: Unable to parse EVENT_EVENT_TAG event from TPM log > ::: 04f9c: event type=EVENT_EVENT_TAG pcr=5 digests=4 data=32 bytes > ::: sha1 01d4e1ca16f118f6fcd954e175c0116c4a4f746b > ::: sha256 > bdbea6dbc6791de89a483abc3a61af8e910249e7565682ff2011c910a490520a > ::: sha384 > 12ebd339e16a134b0aeeb3114bd5b233f9f862037b7550c922a7c73686fa616995273aa751446 > 40d4fb911945d7b5f55 > ::: sha512 > 7c4a18a73955640cde19777b87735f1ca928fe6ef6b54aa3a6d8117c8eaadbd6c00778165a9a3 > 20303644489c242c88a5b2ca6b20be1ffe75f70d5b930f647f6 > ::: Data: > ::: 0000 2a 58 bc f5 18 00 00 00 6c 00 6f 00 61 00 64 00 65 00 72 > 00 2e 00 63 00 6f 00 6e 00 66 00 00 00 *X......l.o.a.d.e.r...c.o.n.f... > Fatal: Aborting. > Error: Failed to install TPM predictions for If I am not wrong this was fixed here: https://github.com/okirch/pcr-oracle/pull/50 Can you check that the version of pcr-oracle running in the snapshot that you are updating from contains this change? """ Tue Feb 20 18:16:53 UTC 2024 - Alberto Planas Dominguez <aplanas@suse.com> - Add fix_loader_conf.patch to measure the systemd-boot loader.conf file """ > Apart from the obvious bug in pcr-oracle, this invalidates any claim of > "immutability" of MicroOS - failed update makes it impossible to boot > MicroOS without human intervention. Yes, there is an issue here: systemd-boot started to measure loader.conf in v255. We updated the pcr-oracle version 20th of February, and the systemd v255 was populated in Factory two weeks ago, at the end of March. That should give 1 month of time for the update. I do not understand how is possible that you have a new systemd, but an old pcr-oracle. I will try to replicate the issue locally, downgrading my current installation.
(In reply to Andrei Borzenkov from comment #0) > Apart from the obvious bug in pcr-oracle, this invalidates any claim of > "immutability" of MicroOS - failed update makes it impossible to boot > MicroOS without human intervention. Also comment here that the ESP, /etc and /var are outside of the transaction. This bug is a very interesting case where a side effect (the update of the boot loader) affect all the transactions at the same time: the new boot loader is visible for all the snapshots. We are thinking how to fix this. One option can be that when doing a rollback, recover the old boot loader from the snapshot. This is the correct approach in general, but if the user select an old snapshot from the boot loader, it is still using the most updated one.
> If I am not wrong this was fixed here: > https://github.com/okirch/pcr-oracle/pull/50 Andrei, can you confirm that the updated version of pcr-oracle from Feb does not have this bug?
This should be fixed, if not feel free to reopen it.