From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 7A894D80D5A for ; Thu, 21 Mar 2024 17:47:02 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=55NtDUneyq5r6dTDcIjryRY2QXwY94Eqi3YqGUKZ60I=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20240206; t=1711043220; v=1; b=3mLgRLjFCsD/47wQFi59Pw0IX9P0UQgJtxiUEqBEz4prPnCFjs33OVX1fjk+x/U+dx6pLElN qyDTPi2FfIFpDjdHKcUT4vNif1mUKzj/3kS7WBf1pWMBhBttKFilZLKBCqrVUedARkuLB2t09Kl uiJT8HN53BwbaNNZzieISDoo7wo5mYpmGGQSIttKpbqYUozbDwnLprn/uA5WYwL3tC9VrWZ/AIV Z4935MyEy822Y3ShlkW0cDdyibGRfroTU6d2mUWRDtw3no8fh+DZxgHzqwzLBEwVcwC9m174+Ye fFspus9VL33OWaKP5h7ET0kVeP+fIA9GeCtxy+pgb9ocA== X-Received: by 127.0.0.2 with SMTP id cOq0YY7687511xnW3zTs4dNu; Thu, 21 Mar 2024 10:47:00 -0700 X-Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by mx.groups.io with SMTP id smtpd.web10.3675.1711043220087822126 for ; Thu, 21 Mar 2024 10:47:00 -0700 X-Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-568c3888ad7so1644a12.0 for ; Thu, 21 Mar 2024 10:46:59 -0700 (PDT) X-Gm-Message-State: wKJtg1wfbij7pFU0W7xMgCkwx7686176AA= X-Google-Smtp-Source: AGHT+IGu9h6gbNtuVZtwQMr3Hv/MhtZla4uv5torE6Ki41lgRBG1CXzaq0OCuj/SAc8vFXlKhyULil0PC7mm+sFcfYQ= X-Received: by 2002:aa7:d703:0:b0:56b:826e:d77d with SMTP id t3-20020aa7d703000000b0056b826ed77dmr184209edq.3.1711043218153; Thu, 21 Mar 2024 10:46:58 -0700 (PDT) MIME-Version: 1.0 References: <94521f20aa2872c1b8f018b7db31eca4a2b8222d.1711039409.git.qinkun@google.com> In-Reply-To: <94521f20aa2872c1b8f018b7db31eca4a2b8222d.1711039409.git.qinkun@google.com> From: "Dionna Glaze via groups.io" Date: Thu, 21 Mar 2024 10:46:45 -0700 Message-ID: Subject: Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR. To: qinkun Bao Cc: devel@edk2.groups.io, linux-coco@lists.linux.dev, Erdem Aktas , Jiewen Yao , Ard Biesheuvel , Peter Gonda , James Bottomley , Gerd Hoffmann , Tom Lendacky , Michael Roth Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Thu, 21 Mar 2024 10:47:00 -0700 Reply-To: devel@edk2.groups.io,dionnaglaze@google.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=3mLgRLjF; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=pass (policy=none) header.from=groups.io On Thu, Mar 21, 2024 at 9:59=E2=80=AFAM qinkun Bao wrot= e: > > From: Qinkun Bao > > The UEFI v2.10 spec defines the protocol EFI_CC_MEASUREMENT_PROTOCOL > to enable (for example) RTMR-based boot measurement for TDX VMs. > With the current UEFI spec=E2=80=99s =E2=80=9Cshould not=E2=80=9D wording= and EDK2 > implementation, TPM measurement in TDVF is disabled when > RTMR measurement is enabled. > > Mutual exclusion of the CC measurement protocol and TCG measurement > protocol breaks backwards compatibility, which makes adoption of RTMRs > challenging. A virtualized TPM device (vTPM) managed by the host VMM > makes boot measurements visible to the VMM operator, but this is an > oft-requested feature that users can choose to accept. > > The TPM has been a standard for over a decade and many existing > applications rely on the TPM. Both inside and outside Google, > we have many users that require vTPM, including features that are > not easily available via RTMRs (e.g. sealing using keys that the > guest OS cannot access). > > This patch adds a non-default build option to allow the coexistence > of both the CC measurement and TCG protocols. Not included is a > vendor-specific measured event in the CC event log that indicates > whether a vTPM is attached or not. Thank you very much for starting this conversation. I'll carry forward more context from our more senior engineers. ' Not measuring into all possible measurement banks led to (CVE-2021-42299) with TPM PCR banks. Let's not repeat this problem. Requiring a monumental shift of all attestation-based applications to CC_MEASUREMENT_PROTOCOL and CEL in one step is going to make the technology very difficult to adopt. ' The combination of these requirements means careful rollout of attestation verification policies to match the updated behavior of the firmware. The measured boot components have to be known to correctly measure into all available measurement protocols and register banks. The firmware has to be known specifically which protocols it makes availabl= e. Now, how this is done is a vendor matter for now. If there is strong demand for making vTPM attachment status known for folks who really don't want a TPM and don't trust the VMM to not attach one anyway, we'll need to agree that the CEL should have an entry for an RTMR0 update detailing the combination of measurement protocols in use. Likewise PCR1 should have an event detailing the protocols in use if we want to make CC_MEASUREMENT_PROTOCOL usage configurable. Philosophizing aside that both protocols should be allowed to be active and that the spec should be updated to say something along the lines of "all measurement protocols that are active (i.e., any combination of EFI_CC_MEASUREMENT_PROTOCOL, EFI_TCG_PROTOCOL, EFI_TCG2_PROTOCOL) should have comparable events measured if any one protocol receives measurements. All measurement protocols that are active MUST measure comparable separator events if any protocol receives a separator event." This is crossing a spec boundary between USWG and TCG, so I don't know where specifically the language needs to go, but we need some language that implementers can use as justification for measuring into any found protocol and not just at most one. It's not lost on me that it is similarly difficult to say that all protocols that are discoverable need to have comparable events measured into them since that _also_ introduces an all-or-nothing migration problem, but at least that's more controllable from the attestation verification policy side than from the UEFI spec side. We're not adding new measurement protocols frequently, so we can get the entire boot chain ready for a new measurement protocol before it's made discoverable. > > Cc: Erdem Aktas > Cc: James Bottomley > Cc: Jiewen Yao > Cc: Gerd Hoffmann > Cc: Tom Lendacky > Cc: Michael Roth > Signed-off-by: Qinkun Bao > --- > OvmfPkg/OvmfPkgX64.dsc | 9 ++++++++- > .../DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c | 12 +++++++++++- > .../DxeTpmMeasurementLib/DxeTpmMeasurementLib.c | 6 ++++++ > 3 files changed, 25 insertions(+), 2 deletions(-) > > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > index 56c920168d..9bcee45047 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -32,7 +32,8 @@ > DEFINE SECURE_BOOT_ENABLE =3D FALSE > DEFINE SMM_REQUIRE =3D FALSE > DEFINE SOURCE_DEBUG_ENABLE =3D FALSE > - DEFINE CC_MEASUREMENT_ENABLE =3D FALSE > + DEFINE CC_MEASUREMENT_ENABLE =3D TRUE > + DEFINE CC_MEASUREMENT_AND_TCG2_COEXIST =3D FASLE > > !include OvmfPkg/Include/Dsc/OvmfTpmDefines.dsc.inc > > @@ -99,6 +100,11 @@ > INTEL:*_*_X64_GENFW_FLAGS =3D --keepexceptiontable > !endif > RELEASE_*_*_GENFW_FLAGS =3D --zero > +!if $(CC_MEASUREMENT_ENABLE) =3D=3D TRUE && $(CC_MEASUREMENT_AND_TCG2_CO= EXIST) =3D=3D TRUE > + MSFT:*_*_*_CC_FLAGS =3D /D CC_MEASUREMENT_AND_TCG2_COEXIST_FEATURE > + INTEL:*_*_*_CC_FLAGS =3D /D CC_MEASUREMENT_AND_TCG2_COEXIST_FEATURE > + GCC:*_*_*_CC_FLAGS =3D -D CC_MEASUREMENT_AND_TCG2_COEXIST_FEATURE > +!endif > > # > # Disable deprecated APIs. > @@ -1045,6 +1051,7 @@ > } > !endif > > + > # > # TPM support > # > diff --git a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBoot= Lib.c b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c > index 73719f3b96..4c9bc8ab4a 100644 > --- a/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c > +++ b/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c > @@ -325,7 +325,12 @@ Tcg2MeasureGptTable ( > } > > DEBUG ((DEBUG_INFO, "DxeTpm2MeasureBootHandler - Cc MeasureGptTable = - %r\n", Status)); > +#ifdef CC_MEASUREMENT_AND_TCG2_COEXIST_FEATURE On to the less philosophical. Thank you for starting this conversation. I do think that this implementation is unideal. These kinds of configuration decisions should be implemented in the form of a Pcd. Whether that's a static or dynamic Pcd is a matter of whether you want to do all the event design of the configuration measurement to MR0~PCR1 at the same time. > + } > + if (Tcg2Protocol !=3D NULL) { > +#else > } else if (Tcg2Protocol !=3D NULL) { > +#endif > // > // If Tcg2Protocol is installed, then Measure GPT data with this pro= tocol. > // > @@ -493,7 +498,12 @@ Tcg2MeasurePeImage ( > CcEvent > ); > DEBUG ((DEBUG_INFO, "DxeTpm2MeasureBootHandler - Cc MeasurePeImage -= %r\n", Status)); > - } else if (Tcg2Protocol !=3D NULL) { > +#ifdef CC_MEASUREMENT_AND_TCG2_COEXIST_FEATURE > + } > + if (Tcg2Protocol !=3D NULL) { > +#else > + } else if (Tcg2Protocol !=3D NULL) { > +#endif > Status =3D Tcg2Protocol->HashLogExtendEvent ( > Tcg2Protocol, > PE_COFF_IMAGE, > diff --git a/SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLi= b.c b/SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.c > index 6f287b31fc..b1c6198b4b 100644 > --- a/SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.c > +++ b/SecurityPkg/Library/DxeTpmMeasurementLib/DxeTpmMeasurementLib.c > @@ -261,7 +261,11 @@ TpmMeasureAndLogData ( > HashData, > HashDataLen > ); > +#ifdef CC_MEASUREMENT_AND_TCG2_COEXIST_FEATURE > + } > +#else > } else { > +#endif > // > // Try to measure using Tpm20 protocol > // > @@ -287,7 +291,9 @@ TpmMeasureAndLogData ( > HashDataLen > ); > } > +#ifndef CC_MEASUREMENT_AND_TCG2_COEXIST_FEATURE > } > +#endif > > return Status; > } > -- > 2.44.0.291.gc1ea87d7ee-goog > -- -Dionna Glaze, PhD (she/her) -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117017): https://edk2.groups.io/g/devel/message/117017 Mute This Topic: https://groups.io/mt/105070442/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-