systemd-pcrlock log fails to read hyper-v vTPMs on Azure

[Matthew Ruffell]

[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 address hidden>
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.

[Matthew Ruffell (mruffell)]

Attached is a debdiff for noble which fixes the problem. Note the patch file has not been refreshed.

[Nick Rosbrook (enr0n)]

Thanks for the patch! I have staged this in my git tree for the next systemd SRU to noble.

[Julian Andres Klode (juliank)]

Hello Matthew, or anyone else affected,

Accepted systemd into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/255.4-1ubuntu8.11 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted systemd (255.4-1ubuntu8.11) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

casper/1.498 (amd64)
collectd/5.12.0-17.1build2 (s390x)
exim4/4.97-4ubuntu4.3 (ppc64el)
haproxy/2.8.5-1ubuntu3.3 (s390x)
linux-azure-6.11/6.11.0-1018.18~24.04.1 (arm64)
linux-gke/6.8.0-1033.37 (arm64)
linux-hwe-6.11/6.11.0-29.29~24.04.1 (ppc64el)
linux-hwe-6.14/unknown (arm64)
linux-nvidia/6.8.0-1036.39 (amd64)
linux-nvidia-6.11/6.11.0-1013.13 (arm64)
linux-nvidia-6.14/6.14.0-1009.9 (amd64)
linux-nvidia-lowlatency/unknown (arm64)
linux-raspi-realtime/6.8.0-2019.20 (arm64)
linux-realtime/6.8.1-1015.16 (arm64)
linux-xilinx/6.8.0-1017.18 (arm64)
mariadb/1:10.11.13-0ubuntu0.24.04.1 (arm64)
ovn/24.03.2-0ubuntu0.24.04.2 (amd64)
sssd/2.9.4-1.1ubuntu6.3 (s390x)
udisks2/2.10.1-6ubuntu1.3 (ppc64el)
upower/1.90.3-1 (ppc64el, s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Matthew Ruffell (mruffell)]

Performing verification for noble.

I created a new "Standard D2s v3" instance on Azure, running noble. The system
has "Trusted Launch" set and has a vTPM.

With systemd from updates:

$ apt-cache policy systemd | grep Installed
  Installed: 255.4-1ubuntu8.10

$ sudo /usr/lib/systemd/systemd-pcrlock log
Hash algorithms in event log record don't match log.

I then enabled -proposed, and installed systemd 255.4-1ubuntu8.11 and rebooted.

$ sudo /usr/lib/systemd/systemd-pcrlock log
PCR PCRNAME EVENT MATCH SHA256 F/U COMPONENT DESC>
  0 █ platform-code s-crtm-version ✓ 96a296d224f285c67bee93c30f8a309157f0daa35dc5b87e410b78630a09cfc7 F - Raw:>
  0 █ platform-code efi-platform-firmware-blob - 2da34fbe343757e290d8e718407ede5f8b9f8920644a4d0f56244097aebbe81a F - Blob>
  7 █ secure-boot-policy efi-variable-driver-config ✓ ccfc4bb32888a345bc8aeadaba552b627d99348c767681ab3141f5b01e40a40e F - Vari>
  7 █ secure-boot-policy efi-variable-driver-config ✓ 827f3ad1828bd20cc03a5624d4ce3f1cf74910715cc764f69800fefd8f406dc6 F - Vari>
  7 █ secure-boot-policy efi-variable-driver-config ✓ f2ff789f4c200f638f38a453c3128398d4f30181c9c4b46ebb32ba5e19c73b0a F - Vari>
  7 █ secure-boot-policy efi-variable-driver-config ✓ c1bc3e1aeb319c357129dc6e8e51c9a92abd135aabec122fca5f6cae0e477686 F - Vari>
  7 █ secure-boot-policy efi-variable-driver-config ✓ 4495e52d2675bd260c90cf42c3f0ae20e41486f857502e3204de0f429d0558c1 F - Vari>
  7 █ secure-boot-policy separator ✓ df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119 F 400-secureboot-separator Sepa>
  6 █ host-platform compact-hash ✓ 3c2a3a23ba49e7ae736ff564bb720158aec6f1baf820704cfec2774cae930027 F - Raw:>
  1 █ platform-config efi-variable-boot ✓ 47dc540c94ceb704a23875c11273e16bb0b8a87aed84de911f2133568115f254 F - Vari>
  1 █ platform-config efi-variable-boot ✓ e1208a5825b4f30cfef7592c6ff8e47f51984e22b2ff1a74e677242bc4c8a746 F - Vari>
  4 █ boot-loader-code efi-action ✓ 3d6772b4f84ed47595d72a2c4c5ffd15f5bb72c7507fe26f2aaee2c69d5633ba F 350-action-efi-application Acti>
  0 █ platform-code separator ✓ df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119 F 500-separator Sepa>
  1 █ platform-config separator ✓ df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119 F 500-separator Sepa>
  2 █ external-code separator ✓ df3f619804a92fdb4057192dc43dd748ea778adc52bc498ce80524c014b81119 F 500-separator Se...

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd - 255.4-1ubuntu8.11

---------------
systemd (255.4-1ubuntu8.11) noble; urgency=medium

  [ Nick Rosbrook ]
  * initramfs-tools: copy hwdb.bin to initramfs (LP: #2112237)
  * d/t/tests-in-lxd: drop patching workaround (LP: #2115263)
    - d/t/control: add Depends: dnsmasq-base
      (Revealed by test progressing past previous failure)
  * initramfs-tools: filter out zdev rules in the initramfs hook (LP: #2044104)
    Backport the logic from plucky onward, but adjust the version string for
    noble.
  * test: fall back to SYSLOG_IDENTIFIER= matching in TEST-75-RESOLVED
    Partially backport the test fix from 49a954b08654dd06bab71224a2398a65c2555549,
    only targeting TEST-75-RESOLVED.

  [ Matthew Ruffell ]
  * pcrlock: handle measurement logs where hash algs in header.
    Fix pcrlock log to function correctly reading the TPM eventlog on hyper-v VMs
    (LP: #2115391)

  [ Chengen Du ]
  * network/dhcp6: consider the DHCPv6 protocol as finished when conflict addresses exist
    (LP: #2115418)

  [ Mario Limonciello ]
  * Drop support for using actual brightness (LP: #2110585)

 -- Nick Rosbrook <email address hidden> Fri, 11 Jul 2025 14:52:59 -0400

[Nick Rosbrook (enr0n)]

The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.