1️⃣0️⃣ Here's the 10th post highlighting key new features of the just published v260 release of systemd. #systemd260 #systemd
As systemd gains more and more TPM support we increasingly run into problems with actual real-life TPM implementations. TPMs run non-trivial firmware after all, and … let's just say …, not all of it is of the highest quality.
When TPM operations fail, and we get a "clean" error back, then we can relatively nicely handle this, implement fallback code paths, and move on.
But of course, long time-outs at boot are very noticeable by users, and simply annoying.
With v260 we do something about it: we now laid the ground work to build up a "hwdb" database of flaky TPM devices. hwdb of course is the udev database logic that can enrich udev properties with secondary metadata that cannot be probed from the devices themselves, but has to be shipped sepatrately.
In order to make this work, we of course need a lookup key for the hwdb, i.e. identifiers for the TPM…
…model and some basic other information that we can use to find the right quirks in the database.
With v260 there's now the "tpm2_id" udev built-in which talks to any TPM as it is attached, extracts manufacturer information, firmware versions and some other fields from it. A set of new udev rules then use this to find suitable metadata in hwdb.
For now, there's only a single entry in the database that makes use of this, that addresses one specific problem of the kind explained above.
Lennart Poettering
steelman