Attached is a debdiff for noble which fixes the problem. Note the patch file has not been refreshed.
** Patch added: "Debdiff for systemd on noble" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2115391/+attachment/5886226/+files/lp2115391_noble.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2115391 Title: systemd-pcrlock log fails to read hyper-v vTPMs on Azure Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Noble: In Progress Bug description: [Impact] On Azure, running "systemd-pcrlock log" fails with: $ sudo /usr/lib/systemd/systemd-pcrlock log Hash algorithms in event log record don't match log. This is because the hyper-v vTPMs announce the hash algorithms in the header in a different order than what is actually written in the log. The patch changes systemd-pcrlock to search for the correct mapping instead of using the order in the header. There are no workarounds. [Testcase] On Azure, boot a VM with Security type set to "Trusted launch virtual machines" or "Confidential virtual machines". I recommend "Trusted launch virtual machines" with size Standard_D2s_v3. Run systemd-pcrlock: $ sudo /usr/lib/systemd/systemd-pcrlock log Hash algorithms in event log record don't match log. The expected result is a screenful of TPM PCR registers with their contents, as well as a colour and an emoji indicating if the computed result is good or not. Test packages are available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf409402-test If you install the test packages, systemd-pcrlock works as expected. [Where problems can occur] This changes how systemd-pcrlock opens and reads the tpm2 eventlog. This should be just a readonly operation, so a regression would not tamper with or modify any TPM PCR registers. If a regression were to occur, users could potentially not be able to run "systemd-pcrlock log" against their TPMs on their systems, and not be able to verify attestation of their boot. A regression could also prevent users from using systemd-pcrlock to predict the next set of TPM PCR values when installing a new kernel image to their system, which might mean they would have to determine the correct PCR values manually. A workaround is to use the non-related tpm2-tools package for these calculations and reading the eventlog. [Other info] This was fixed in 256-rc1 by: commit e90a255e55e3af0effac927ccaa10c2662501e1a From: Lennart Poettering <[email protected]> Date: Wed, 21 Feb 2024 14:43:42 +0100 Subject: pcrlock: handle measurement logs where hash algs in header are announced in different order than in records Link: https://github.com/systemd/systemd/commit/e90a255e55e3af0effac927ccaa10c2662501e1a This is in oracular onward, and jammy doesn't have pcrlock, so only noble needs the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2115391/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
