tpm: Document UEFI event log quirks
There are some weird quirks when it comes to UEFI event log. Provide a brief introduction to TPM event log mechanism and describe the quirks and how they can be sorted out. Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
parent
e15d5a53ea
commit
2ef5a7f148
|
@ -4,5 +4,6 @@ Trusted Platform Module documentation
|
||||||
|
|
||||||
.. toctree::
|
.. toctree::
|
||||||
|
|
||||||
|
tpm_event_log
|
||||||
tpm_vtpm_proxy
|
tpm_vtpm_proxy
|
||||||
xen-tpmfront
|
xen-tpmfront
|
||||||
|
|
|
@ -0,0 +1,55 @@
|
||||||
|
.. SPDX-License-Identifier: GPL-2.0
|
||||||
|
|
||||||
|
=============
|
||||||
|
TPM Event Log
|
||||||
|
=============
|
||||||
|
|
||||||
|
This document briefly describes what TPM log is and how it is handed
|
||||||
|
over from the preboot firmware to the operating system.
|
||||||
|
|
||||||
|
Introduction
|
||||||
|
============
|
||||||
|
|
||||||
|
The preboot firmware maintains an event log that gets new entries every
|
||||||
|
time something gets hashed by it to any of the PCR registers. The events
|
||||||
|
are segregated by their type and contain the value of the hashed PCR
|
||||||
|
register. Typically, the preboot firmware will hash the components to
|
||||||
|
who execution is to be handed over or actions relevant to the boot
|
||||||
|
process.
|
||||||
|
|
||||||
|
The main application for this is remote attestation and the reason why
|
||||||
|
it is useful is nicely put in the very first section of [1]:
|
||||||
|
|
||||||
|
"Attestation is used to provide information about the platform’s state
|
||||||
|
to a challenger. However, PCR contents are difficult to interpret;
|
||||||
|
therefore, attestation is typically more useful when the PCR contents
|
||||||
|
are accompanied by a measurement log. While not trusted on their own,
|
||||||
|
the measurement log contains a richer set of information than do the PCR
|
||||||
|
contents. The PCR contents are used to provide the validation of the
|
||||||
|
measurement log."
|
||||||
|
|
||||||
|
UEFI event log
|
||||||
|
==============
|
||||||
|
|
||||||
|
UEFI provided event log has a few somewhat weird quirks.
|
||||||
|
|
||||||
|
Before calling ExitBootServices() Linux EFI stub copies the event log to
|
||||||
|
a custom configuration table defined by the stub itself. Unfortunately,
|
||||||
|
the events generated by ExitBootServices() don't end up in the table.
|
||||||
|
|
||||||
|
The firmware provides so called final events configuration table to sort
|
||||||
|
out this issue. Events gets mirrored to this table after the first time
|
||||||
|
EFI_TCG2_PROTOCOL.GetEventLog() gets called.
|
||||||
|
|
||||||
|
This introduces another problem: nothing guarantees that it is not called
|
||||||
|
before the Linux EFI stub gets to run. Thus, it needs to calculate and save the
|
||||||
|
final events table size while the stub is still running to the custom
|
||||||
|
configuration table so that the TPM driver can later on skip these events when
|
||||||
|
concatenating two halves of the event log from the custom configuration table
|
||||||
|
and the final events table.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
- [1] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/
|
||||||
|
- [2] The final concatenation is done in drivers/char/tpm/eventlog/efi.c
|
Loading…
Reference in New Issue