From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 966D3C0650E for ; Wed, 3 Jul 2019 17:08:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 741802187F for ; Wed, 3 Jul 2019 17:08:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727180AbfGCRIk (ORCPT ); Wed, 3 Jul 2019 13:08:40 -0400 Received: from linux.microsoft.com ([13.77.154.182]:33640 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726430AbfGCRIj (ORCPT ); Wed, 3 Jul 2019 13:08:39 -0400 Received: from [10.91.6.157] (unknown [131.107.159.157]) by linux.microsoft.com (Postfix) with ESMTPSA id 7C54E20BCFB8; Wed, 3 Jul 2019 10:08:38 -0700 (PDT) Subject: Re: [PATCH] tpm: Document UEFI event log quirks To: Jarkko Sakkinen , linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org Cc: tweek@google.com, matthewgarrett@google.com, Jonathan Corbet References: <20190703161109.22935-1-jarkko.sakkinen@linux.intel.com> From: Jordan Hand Message-ID: Date: Wed, 3 Jul 2019 10:08:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190703161109.22935-1-jarkko.sakkinen@linux.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/3/19 9:11 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 > --- > Documentation/security/tpm/tpm-eventlog.rst | 53 +++++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/security/tpm/tpm-eventlog.rst > > diff --git a/Documentation/security/tpm/tpm-eventlog.rst b/Documentation/security/tpm/tpm-eventlog.rst > new file mode 100644 > index 000000000000..2ca8042bdb17 > --- /dev/null > +++ b/Documentation/security/tpm/tpm-eventlog.rst > @@ -0,0 +1,53 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +============= > +TPM Event Log > +============= > + > +| Authors: > +| Stefan Berger > + > +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() do end up to the table. do not > + > +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 stub gets to run. Thus, it needs to copy the final > +events table preboot size to the custom configuration table so that > +kernel offset it later on. This doesn't really explain what the size will be used for. Matthew's patch description for "tpm: Don't duplicate events from the final event log in the TCG2 log" outlines this well. You could maybe word it differently but I think the information is necessary: "We can avoid this problem by looking at the size of the Final Event Log just before we call ExitBootServices() and exporting this to the main kernel. The kernel can then skip over all events that occured before ExitBootServices() and only append events that were not also logged to the main log." > + > +[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 > Thanks, Jordan