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 56B13D8081E for ; Tue, 26 Mar 2024 15:52:20 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=TSmLgn1U7jPLijPZyKdi2YoDm5QFpltcehlAJmXfngo=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition:Content-Transfer-Encoding; s=20240206; t=1711468339; v=1; b=waut8EABynGQYbvumCJczAOSUyhlEZUwVe/+6YPZ1x3DG9+J/fpN3+bp7yEkgWhaEmcjyJ05 T1RGaVFVcorajGonTcG96me6stnDDUsb0+6uES08wujN48Jj1U7GHsjEeif05+Z6OuFxmT13ngA LEmnw5uMA5ckXyN0fMDM+1j1ovaUNmje4tzcJKSy6cXnc6B9Gsap9vVY5cGvL9z8LRynvCdr5uw CpjZYvf/ug/r1vvY9iuMdsl0MZ4VUK74oDgezVmWL6rABC0dAqD6TWhWAnVF9t3s13+ms86ZgYb PfL7pU3WCzniYqeddsifthb71Iwr760I7j0Xf0yQx20bA== X-Received: by 127.0.0.2 with SMTP id Di6hYY7687511xLQv2muY7Ug; Tue, 26 Mar 2024 08:52:19 -0700 X-Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) by mx.groups.io with SMTP id smtpd.web10.51536.1711372047816016674 for ; Mon, 25 Mar 2024 06:07:27 -0700 X-IronPort-AV: E=McAfee;i="6600,9927,11023"; a="10165348" X-IronPort-AV: E=Sophos;i="6.07,153,1708416000"; d="scan'208";a="10165348" X-Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2024 06:07:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,153,1708416000"; d="scan'208";a="15639830" X-Received: from kmreisi-mobl1.ger.corp.intel.com (HELO himmelriiki) ([10.251.212.8]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2024 06:07:21 -0700 Date: Mon, 25 Mar 2024 15:07:12 +0200 From: Mikko Ylinen To: Dionna Amalie Glaze Cc: Gerd Hoffmann , "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 Subject: Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR. Message-ID: References: <94521f20aa2872c1b8f018b7db31eca4a2b8222d.1711039409.git.qinkun@google.com> MIME-Version: 1.0 In-Reply-To: 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: Tue, 26 Mar 2024 08:52:15 -0700 Reply-To: devel@edk2.groups.io,mikko.ylinen@linux.intel.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: vgyaDALCErmDwGQLZD6l8uRtx7686176AA= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b=waut8EAB; 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=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=intel.com (policy=none) On Fri, Mar 22, 2024 at 07:56:53AM -0700, Dionna Amalie Glaze wrote: > On Fri, Mar 22, 2024 at 1:52 AM Gerd Hoffmann wrote: > > > > 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/126a07ebc30bbd203b6966465b058da741b2654b/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. FWIW, my RTMRs patch to systemd was merged quite recently so it's not included in any systemd release yet. (It was mainly implemented for the UKI case that allows TDVF to boot a UKI image directly and then have the image sections measured separately.) > 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 6.9-rc1 we have it: ac93cbfc > > > 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 -- Regards, Mikko -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117134): https://edk2.groups.io/g/devel/message/117134 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] -=-=-=-=-=-=-=-=-=-=-=-