Bug#1023515: systemd-pcrphase sysinit hangs blocking boot when tpm2-abrmd installed

[Marek Rusinowski]

Package: systemd
Version: 252-2
Severity: important
X-Debbugs-Cc: marekru...@gmail.com

Dear Maintainer,

In systemd 252 a new tool systemd-pcrphase got included that
measures PCR values at different boot stages. When tpm2-abrmd is
installed in the system, the sysinit stage of that tool
systemd-pcrphase-sysinit.service will hang when initializing tpm2
context on trying to connect via dbus to running tpm2-abrmd daemon
because this daemon is not yet running in this point during the boot
process. This blocks the whole boot sequence as timelimit on
systemd-pcrphase-sysinit is infinite.

Resolution for me was to purge from the system tpm2-abrmd and
libtss2-tcti-tabrmd0 packages so that the tpm2 initialization
doesn't try to use this daemon but contacts tpm2 device using a
different method.

I've confirmed and figured out above by using systemd debug shell
and running `systemd-pcrphase sysinit` under gdb, the stacktrace
looked like:
#0 __GI__poll
(...)
#17 Tss2_Tcti_Tabrmd_Init
(...)
#24 Esys_Initialize (libtss2-esys)
#25 tpm2_context_init (libsystemd-shared)

Thank you,
Marek


-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii libacl1 2.3.1-1
ii libaudit1 1:3.0.7-1.1+b1
ii libblkid1 2.38.1-1.1+b1
ii libc6 2.36-4
ii libcap2 1:2.44-1
ii libcryptsetup12 2:2.5.0-6
ii libfdisk1 2.38.1-1.1+b1
ii libgcrypt20 1.10.1-2
ii libkmod2 30+20220905-1
ii liblz4-1 1.9.4-1
ii liblzma5 5.2.7-0.1
ii libmount1 2.38.1-1.1+b1
ii libseccomp2 2.5.4-1+b1
ii libselinux1 3.4-1+b2
ii libssl3 3.0.7-1
ii libsystemd-shared 252-2
ii libsystemd0 252-2
ii libzstd1 1.5.2+dfsg-1
ii mount 2.38.1-1.1+b1

Versions of packages systemd recommends:
ii dbus [default-dbus-system-bus] 1.14.4-1
ii systemd-timesyncd [time-daemon] 252-2

Versions of packages systemd suggests:
ii libfido2-1 1.12.0-1
ii libtss2-esys-3.0.2-0 3.2.0-1+b1
ii libtss2-mu0 3.2.0-1+b1
ii libtss2-rc0 3.2.0-1+b1
ii policykit-1 122-1
ii systemd-boot 252-2
ii systemd-container 252-2
pn systemd-homed <none>
pn systemd-resolved <none>
pn systemd-userdbd <none>

Versions of packages systemd is related to:
ii dbus-user-session 1.14.4-1
pn dracut <none>
ii initramfs-tools 0.142
ii libnss-systemd 252-2
ii libpam-systemd 252-2
ii udev 252-2

-- no debconf information

[Luca Boccassi]

I thought these days in-kernel resource management was preferred? Any
reason you were using abrmd?

--
Kind regards,
Luca Boccassi

[Marek Rusinowski]

> I thought these days in-kernel resource management was preferred? Any
> reason you were using abrmd?

I just still had it installed already for a long time since times where most
places were suggesting using it and never dropped.

Thank you for fixing it!

[Michael Biebl]

Am 11.11.22 um 20:47 schrieb Marek Rusinowski:

Do you remember what triggered the installation of tmp2-abrmd?

> Thank you for fixing it!
>

Should the systemd package have a Conflicts: tpm2-abrmd?
Apparently the both packages don't play along nicely.


@Luca: you closed this bug report, and I wonder why?

[Marek Rusinowski]

> Do you remember what triggered the installation of tmp2-abrmd?

The most likely is I have just installed it manually late 2017, or
2018 when I started playing with the tpm2 setup for FDE following
guidance from some documentation. I will not recall any more details
after so much time.

[Luca Boccassi]

On Mon, 14 Nov 2022 15:01:00 +0100 Michael Biebl <bi...@debian.org>
wrote:

Workaround that will stop the race condition was backported to 252.1:

https://github.com/systemd/systemd-stable/commit/1757446e8bc4dc076badd5c1ad53a0021c42638c

No need for a conflict, for the next release we'll fix it to force
using the kernel driver as the default. On old systems with older tpms
the userspace manager might be needed for late-boot stuff, which is a
legitimate use case. It's the early-boot usage that is a problem.

[Michael Biebl]

Hi Luca

Am 16.11.22 um 10:51 schrieb Luca Boccassi:

> On Mon, 14 Nov 2022 15:01:00 +0100 Michael Biebl <bi...@debian.org>
> wrote:

>> @Luca: you closed this bug report, and I wonder why?
>
> Workaround that will stop the race condition was backported to 252.1:
>
> https://github.com/systemd/systemd-stable/commit/1757446e8bc4dc076badd5c1ad53a0021c42638c

Ah, ok. I thought this required
https://github.com/systemd/systemd/pull/25393 which is not yet available
in the Debian package.
If 1757446e8bc4dc076badd5c1ad53a0021c42638c is indeed already
sufficient, then a short ref to the upstream commit in the close message
would have been great as this would have avoided any confusion (on my side).

>
> No need for a conflict, for the next release we'll fix it to force
> using the kernel driver as the default. On old systems with older tpms
> the userspace manager might be needed for late-boot stuff, which is a
> legitimate use case. It's the early-boot usage that is a problem.
>

Agreed, if no conflicts is necessary, even better.
The popcon number of tpm2-abrmd is rather high [1] and I don't see a
package Depending or Recommending it. So I wonder why that is (did/does
d-i install it?) and if we can/should do something about it.


Regards,
Michael

[1] https://qa.debian.org/popcon.php?package=tpm2-abrmd