debcrafters-packages team mailing list archive
-
debcrafters-packages team
-
Mailing list archive
-
Message #06466
[Bug 2115391] Autopkgtest regression report (systemd/255.4-1ubuntu8.11)
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!
--
You received this bug notification because you are a member of
Debcrafters 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:
Fix Committed
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 <lennart@xxxxxxxxxxxxxx>
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
References