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 5279D740035 for ; Fri, 22 Mar 2024 14:57:12 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=WT6T8SLlrr38Qzzuf6vpZlQfnRq+JV7DK4HFLic45Q0=; 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=1711119431; v=1; b=HU5TZmq+93vdBj5cqAXQ7+LDowQeZWAABfMaG2hZIcW/GDagDsqlXVpK157Bb2TLmZqM2/6O b2ilZtgrTVBS+TNzEuOxN6kXpVZGTlhlBD6QOXfUTEGW+nDff/cyKGpvqlAyamb4co5Av2+I+Vx +oSdcukJr0Ornt4tMUu8Dgb8VLhvRlifmz+YHUy6ObEyF0G+D6kX2n5CEZDExZNPLO2H7Q4ZHUN a/S94JbILsSCX3qJiIzbDbhn65gEZ3OuH9dgDV0keieiEjVeFjzRxlXhEqKCJXBIkFH7iHtA3Lb 7X2qJizoKd80HbEGztxV13lUH9LwWxPzykW0U19jsXoxA== X-Received: by 127.0.0.2 with SMTP id WbwRYY7687511xZwcGc0I6qd; Fri, 22 Mar 2024 07:57:11 -0700 X-Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by mx.groups.io with SMTP id smtpd.web11.15584.1711119430083344704 for ; Fri, 22 Mar 2024 07:57:10 -0700 X-Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-56bde8ea904so13003a12.0 for ; Fri, 22 Mar 2024 07:57:09 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVowWXtftXsd+9cnLEC9VAnIE6bI3AHO96yxPmVqmSKL4H3qMcZqZf7p8dEEr9oXGHxx/EOXepjYqDwwBXdNAemmdidiw== X-Gm-Message-State: 9wpRxCllYJLUxbLBGFi1Zrwex7686176AA= X-Google-Smtp-Source: AGHT+IFOiWKhRImotom6fWI+3OgOejItV+EmnDvUyXMlFBabAf8s4wPRSFGts8XMn8rniX0yzs1g5+Xct/LW7mwt2ck= X-Received: by 2002:aa7:c842:0:b0:568:ce1e:94e5 with SMTP id g2-20020aa7c842000000b00568ce1e94e5mr370371edt.5.1711119428110; Fri, 22 Mar 2024 07:57:08 -0700 (PDT) MIME-Version: 1.0 References: <94521f20aa2872c1b8f018b7db31eca4a2b8222d.1711039409.git.qinkun@google.com> In-Reply-To: From: "Dionna Glaze via groups.io" Date: Fri, 22 Mar 2024 07:56:53 -0700 Message-ID: Subject: Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR. To: Gerd Hoffmann Cc: "Yao, Jiewen" , qinkun Bao , "devel@edk2.groups.io" , "linux-coco@lists.linux.dev" , "Aktas, Erdem" , Ard Biesheuvel , Peter Gonda , James Bottomley , 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: Fri, 22 Mar 2024 07:57:10 -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=HU5TZmq+; dmarc=pass (policy=none) header.from=groups.io; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Fri, Mar 22, 2024 at 1:52=E2=80=AFAM Gerd Hoffmann w= rote: > > On Fri, Mar 22, 2024 at 02:39:20AM +0000, Yao, Jiewen wrote: > > Please aware that this option will cause potential security risk. > > > > In case that any the guest component only knows one of vTPM or RTMR, > > and only extends one of vTPM or RTMR, but the other one only verifies > > the other, then the chain of trust is broken. This solution is secure > > if and only if all guest components aware of coexistence, and can > > ensure all measurements are extended to both vTPM and RTMR. But I am > > not sure if all guest components are ready today. > > As far I know (it's been a while I looked at those patches) shim.efi and > grub.efi have support for EFI_CC_MEASUREMENT_PROTOCOL, but use the same > logic we have in DxeTpm2MeasureBootLib, i.e. they will not measure to > both RTMR and vTPM. Shim will measure into CC and then continue to measure into TPM https://github.com/rhboot/shim/blob/126a07ebc30bbd203b6966465b058da741b2654= b/tpm.c#L164 GRUB2 has the same behavior. We can at least get coexistence supporting the current boot integrity strategy that Confidential Space is using, which is to depend on a dmverity initramfs whose root hash is in the kernel_cmdline, and a Linux kernel built with LOADPIN. The changes to Linux are proposed but not accepted precisely due to this conversation we're having now. I recall describing this to another CSP engineer at an IETF meeting and they claimed they used the same approach, but I can't remember if that was Oracle or another company. > > Looking at systemd-boot I see it will likewise not measure to both RTMR > and vTPM, but with reversed priority (use vTPM not RTMR in case both are > present). > Interesting. Thanks for this report. We'll push for the changed semantics here if the spec is indeed changed, and request partner distros in the CCC to include the updated systemd-boot. I think that since the current boot integrity story stops at PCR9, we have time to update this component before the attestation method evolves to support a less special-purpose system composition. > Linux kernel appears to not have EFI_CC_MEASUREMENT_PROTOCOL support. > > > Since this option caused a potential risk / misuse breaking the chain > > of trust, I recommend we have at least one more company to endorse the > > runtime co-existence of vTPM and RTMR. Also, I would like to hear the > > opinions from other companies. > > Rumors say intel is working on coconut-svsm support for tdx. That will > most likely allow to use a vTPM with tdx even without depending on the > virtualization host or cloud hyperscaler providing one. We will see VMs > with both RTMR and vTPM and surely need a strategy how guests should > deal with that situation, consistent across the whole boot stack and > not every component doing something different. > An ephemeral TPM that Coconut-svsm offers is qualitatively different than the persistent TPMs in CSPs today. Users of Confidential VMs all have different threat models that allow for trusting a CSP-managed vTPM for sealing keys but not for trusting unencrypted data in use. The boot stack attestation story will not be fully resolved for a long while, and a smooth transition is better than a jarring one. > Given that the vTPM might be provided by the hypervisor and thus not be > part of the TCB I can see that guests might want use both vTPM and RTMR. > So, yes, for that case coexistance makes sense. I'm not convinced it is > a good idea to make that a compile time option though. That will not > help to promote a consistent story ... > I agree, but it does mean we have to change the event log composition to describe the configured measurement services like described above. I think a static Pcd is okay to begin with. The idea for tracking these qualities is through software supply chain endorsements. Eventually that would look like the proposed in-toto's SCAI [1] but until then we'd have a bespoke format that we document and integrate with in an attestation verification service. [1] https://arxiv.org/pdf/2210.05813.pdf --=20 -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 (#117055): https://edk2.groups.io/g/devel/message/117055 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-