BROADCASTS.com

The TPM event log contains a history of all measurements made with the TPM.\nComplete with some context information for each measurement it is intended to\nhelp with recreating the current PCR contents. What was meant as a debugging\ntool turns out to be of vital importance when trying to remotely attest real\nlife systems. This is mostly because of the overuse of certain PCR and the\ngeneral mess that is x86\nfirmware. \n\nSadly, there are many event logs. UEFI keeps one for its measurements and those\ndone by EFI applications like GRUB and shim. If a system is booted in an MLE\nusing tboot the ACM firmware code also maintains an event log that can be\naccessed via a pointer in an ACPI table. Now, systemd also has an event log\nthat is mixed into the general journal log. Finally Linux IMA maintains it's\nown event log -- an append-only, in-kernel data structure.\n\nOn top of that every bootloader or userspace application that wants to measure\nsomething into the TPM will also need to maintain an event log. \n\nHow about we fix that? The talk will sketch out a solution that maintains a\nunified, global event log of the whole system on disk and exposes an interface for\nother applications that wish to measure things into the TPM. We'll also fix a\nrace conditions in IMA as well as correctly handle S3 resume w.r.t measured boot\nwhile we're at it.\nabout this event: https://cfp.all-systems-go.io/all-systems-go-2023/talk/HGMV9U/