On 7/12/19 5:49 AM, Jarkko Sakkinen wrote: > 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@xxxxxxxxxxxxxxx> > --- > v3: Add a section and use bullet list for references. Remove (invalid) > author info. > v2: Fixed one type, adjusted the last paragraph and added the file is that typo or type? (one more below) > to index.rst > Documentation/security/tpm/index.rst | 1 + > Documentation/security/tpm/tpm_event_log.rst | 55 ++++++++++++++++++++ > 2 files changed, 56 insertions(+) > create mode 100644 Documentation/security/tpm/tpm_event_log.rst > > diff --git a/Documentation/security/tpm/index.rst b/Documentation/security/tpm/index.rst > index 15783668644f..9e0815cb1e7f 100644 > --- a/Documentation/security/tpm/index.rst > +++ b/Documentation/security/tpm/index.rst > @@ -4,5 +4,6 @@ Trusted Platform Module documentation > > .. toctree:: > > + tpm_event_log > tpm_ftpm_tee > tpm_vtpm_proxy > diff --git a/Documentation/security/tpm/tpm_event_log.rst b/Documentation/security/tpm/tpm_event_log.rst > new file mode 100644 > index 000000000000..068eeb659bb9 > --- /dev/null > +++ b/Documentation/security/tpm/tpm_event_log.rst > @@ -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. Unfortanely, [again:] 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 > -- ~Randy
