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=-11.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=no 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 F13FBC433DF for ; Tue, 30 Jun 2020 18:33:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD30B20768 for ; Tue, 30 Jun 2020 18:33:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="XCR6/KNi" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732786AbgF3SdZ (ORCPT ); Tue, 30 Jun 2020 14:33:25 -0400 Received: from linux.microsoft.com ([13.77.154.182]:51038 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729676AbgF3SdZ (ORCPT ); Tue, 30 Jun 2020 14:33:25 -0400 Received: from sequoia (162-237-133-238.lightspeed.rcsntx.sbcglobal.net [162.237.133.238]) by linux.microsoft.com (Postfix) with ESMTPSA id 6AC6720B717A; Tue, 30 Jun 2020 11:33:23 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 6AC6720B717A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1593542004; bh=P8hrpLXW1bm+I0RtahNav7d3UiFywHUi9+V3kW2yqYE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XCR6/KNiEgjEaGmIFHHaIalSw46WRASLd42p0kaCSzM2PloibciuQ6Ca7BpcNHaEF fiBOSjY9l3V2bp4c4mkWCoe/3MO1u/4l6cUOT2mGAH9qXByYLlrOrSa8yTvMe6Guto RPw934ZtLlanwfAFvAT0OXWavNN3sLhY4Guwmfe0= Date: Tue, 30 Jun 2020 13:33:21 -0500 From: Tyler Hicks To: Jarkko Sakkinen Cc: Ard Biesheuvel , Matthew Garrett , Peter Jones , Peter Huewe , Jason Gunthorpe , Petr Vandrovec , Nayna Jain , Thirupathaiah Annapureddy , linux-integrity , linux-efi , Linux Kernel Mailing List Subject: Re: [PATCH] tpm: Require that all digests are present in TCG_PCR_EVENT2 structures Message-ID: <20200630183321.GE4694@sequoia> References: <20200615232504.1848159-1-tyhicks@linux.microsoft.com> <20200617230958.GC62794@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200617230958.GC62794@linux.intel.com> Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On 2020-06-18 02:09:58, Jarkko Sakkinen wrote: > On Tue, Jun 16, 2020 at 11:08:38AM +0200, Ard Biesheuvel wrote: > > (cc Matthew and Peter) > > > > On Tue, 16 Jun 2020 at 01:28, Tyler Hicks wrote: > > > > > > Require that the TCG_PCR_EVENT2.digests.count value strictly matches the > > > value of TCG_EfiSpecIdEvent.numberOfAlgorithms in the event field of the > > > TCG_PCClientPCREvent event log header. Also require that > > > TCG_EfiSpecIdEvent.numberOfAlgorithms is non-zero. > > > > > > The TCG PC Client Platform Firmware Profile Specification section 9.1 > > > (Family "2.0", Level 00 Revision 1.04) states: > > > > > > For each Hash algorithm enumerated in the TCG_PCClientPCREvent entry, > > > there SHALL be a corresponding digest in all TCG_PCR_EVENT2 structures. > > > Note: This includes EV_NO_ACTION events which do not extend the PCR. > > > > > > Section 9.4.5.1 provides this description of > > > TCG_EfiSpecIdEvent.numberOfAlgorithms: > > > > > > The number of Hash algorithms in the digestSizes field. This field MUST > > > be set to a value of 0x01 or greater. > > > > > > Enforce these restrictions, as required by the above specification, in > > > order to better identify and ignore invalid sequences of bytes at the > > > end of an otherwise valid TPM2 event log. Firmware doesn't always have > > > the means necessary to inform the kernel of the actual event log size so > > > the kernel's event log parsing code should be stringent when parsing the > > > event log for resiliency against firmware bugs. This is true, for > > > example, when firmware passes the event log to the kernel via a reserved > > > memory region described in device tree. > > > > > > > When does this happen? Do we have code in mainline that does this? > > > > > Prior to this patch, a single bit set in the offset corresponding to > > > either the TCG_PCR_EVENT2.eventType or TCG_PCR_EVENT2.eventSize fields, > > > after the last valid event log entry, could confuse the parser into > > > thinking that an additional entry is present in the event log. This > > > patch raises the bar on how difficult it is for stale memory to confuse > > > the kernel's event log parser but there's still a reliance on firmware > > > to properly initialize the remainder of the memory region reserved for > > > the event log as the parser cannot be expected to detect a stale but > > > otherwise properly formatted firmware event log entry. > > > > > > Fixes: fd5c78694f3f ("tpm: fix handling of the TPM 2.0 event logs") > > > Signed-off-by: Tyler Hicks > > > --- > > > > I am all for stringent checks, but this could potentially break > > measured boot on systems that are working fine today, right? > > There would not be any sane reason to implement a TPM chip like that. Jarkko, is this an ack from you? Is there anything I can do to help along this fix? I've spoke with two others that have poured through these specs to implement firmware event log parsers and they thought the change made sense. Tyler > > /Jarkko