debcrafters-packages team mailing list archive

[Matthew Ruffell <2115391@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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

** Affects: systemd (Ubuntu)
     Importance: Undecided
         Status: Fix Released

** Affects: systemd (Ubuntu Noble)
     Importance: Medium
     Assignee: Matthew Ruffell (mruffell)
         Status: In Progress


** Tags: sts

** Also affects: systemd (Ubuntu Noble)
   Importance: Undecided
       Status: New

** Changed in: systemd (Ubuntu)
       Status: New => Fix Released

** Changed in: systemd (Ubuntu Noble)
       Status: New => In Progress

** Changed in: systemd (Ubuntu Noble)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Noble)
     Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Tags added: sts

-- 
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:
  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 <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