[systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)

[Mikko Rapeli]

Hi,

On Tue, Apr 16, 2024 at 04:03:25PM +0200, Lennart Poettering wrote:
> On Di, 16.04.24 15:02, Mikko Rapeli (mikko.rapeli at linaro.org) wrote:
> 
> > Hi,
> >
> > On Mon, Apr 15, 2024 at 05:41:00PM +0200, Lennart Poettering wrote:
> > > Would be good to have that with systemd.log_target=debug, to see if
> > > tpm2.target even gets enqueued.
> >
> > Here is the verbose log:
> >
> > https://people.linaro.org/~mikko.rapeli/systemd_255_tpm2_target_qemu_swtpm_boot_encryption_failure.txt
> 
> So that shows that tpm2.target is only enqueued once the /dev/tpmrm0
> device actually shows up. But that makes it useless. The idea is that
> the target is already enqueued when during very early setup in
> systemd-tpm2-generator we come to the conclusion that "yes, a tpm2
> device has not been found and set up by Linux yet, but the firmware
> indicates there is one, hence let's schedule a job for it, that
> everything can sync on". But this determination never happened
> here, tpm2.target was never enqueued, hence never acted as a
> synchronization milestone.
> 
> (As a temporary hack you can *force* systemd-tpm2-generator to assume
> that a TPM device will show up via systemd.tpm2_wait=1 on the kernel
> cmdline, and thus enqueue tpm2.target. But that's only suitable as
> local hack: we should be able to determine all this automatically
> based on firmware properties, see below.)

Thanks, this is useful. I will try this out.
 
> > System is qemu arm64 with UEFI / ARM System Ready compatible firmware,
> > secure boot and TPM2 device via swtpm.
> 
> So this firmware implements UEFI and ACPI? As indication whether the
> firmware supports TPM2, we check for the existance of the
> /sys/firmware/acpi/tables/TPM2 ACPI table. Does that exist for you?

On qemu with swtpm, no this doesn't exist.

> See src/share/efi-api.c, function efi_has_tpm2().
> 
> Do you have /sys/kernel/security/tpm0/binary_bios_measurements?

But this does exist.

> > systemd-tpm2-setup-early.service: ConditionSecurity=measured-uki
> > failed.
> 
> So this suggests you haven't booted the system with a UKI or that your
> firmware doesn#t actually do TPM.

It's the latter. In this, granted artificial, case firmware doesn't know
about TPM implemented by swtpm but it is setup as a char devices to qemu.
I guess I could amend this in this configuration to be
ConditionSecurity=tpm2 which would enable TPM use even firmware support
for it doesn't exist.

This changed between 254 and 255 but I think I got the reasons now.

What is a bit odd is that when kernel modules are built into the kernel,
then all of these work and ConditionSecurity=measured-uki is true.
Also in this case /sys/firmware/acpi/tables/TPM2 does not exist
but /sys/kernel/security/tpm0/binary_bios_measurements does.

Full log here:

https://people.linaro.org/~mikko.rapeli/systemd_255_tpm2_target_qemu_swtpm_boot_encryption_passing.txt

Cheers,

-Mikko

> Or in other words: ConditionSecurity=measured-uki will only hold if
> the aforementioned ACPI table exists *and* the StubPcrKernelImage EFI
> variable is found to be set.
> 
> Lennart