Message ID | 20190712124912.23630-1-jarkko.sakkinen@linux.intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v3] tpm: Document UEFI event log quirks | expand |
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@linux.intel.com> > --- > 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 >
On Fri, 2019-07-12 at 07:55 -0700, Randy Dunlap wrote: > +Before calling ExitBootServices() Linux EFI stub copies the event log to > > +a custom configuration table defined by the stub itself. Unfortanely, > > [again:] Unfortunately, Ugh, I'm sorry. Sent an update. /Jarkko
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, +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
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> --- 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 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