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 CFFA2AC0DE4 for ; Fri, 22 Mar 2024 08:52:17 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=NOCRX3I67kMSvrC5QVFsn+rA1WVB+wKwNL3hJqQ3+YY=; 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; s=20240206; t=1711097536; v=1; b=n/3fcjFd4+YdzaO6KWJGRcLwE7YcMFvVlj6LkfhZHQIRDLRdUW/u5W3X/kHjFVTdz+CfIjv3 TH/yK1Cj1Np9sZNN6UqPCvEU2jbTOtL4QhDCn0L683dsTEn+t4J/Iyg9CT1X2qvBUdblb0hkNC2 T7IVT9tW0FBnbelPoL94zRiSJLrLnfimnmwhqqxqGYxtRCdmFTyA2RAF3Uf9XwPub7e8lulBdgJ bIEyPAE3bGoQtkoLjV0TfOY8cwN3O+/nSOklkgDnEij9jU70bkKYIZDffBxPdDoV5+oj3AR42+/ wdP78e/nuqLvRi6yfirYj6j8WM5ExyzBGvEUzGjwFGzvQ== X-Received: by 127.0.0.2 with SMTP id Y9ZVYY7687511xtWCY0zCFHe; Fri, 22 Mar 2024 01:52:16 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.8516.1711097535571545837 for ; Fri, 22 Mar 2024 01:52:15 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-614-Cixhu4eCOoSd1-1_R50ACA-1; Fri, 22 Mar 2024 04:52:11 -0400 X-MC-Unique: Cixhu4eCOoSd1-1_R50ACA-1 X-Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7B4BD85530C; Fri, 22 Mar 2024 08:52:10 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.192.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1F6201C060CE; Fri, 22 Mar 2024 08:52:10 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id E1E7518014AE; Fri, 22 Mar 2024 09:52:04 +0100 (CET) Date: Fri, 22 Mar 2024 09:52:04 +0100 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: Dionna Amalie Glaze , 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: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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 01:52:15 -0700 Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 39t93kk16DZBO6lVEpuJ7EQUx7686176AA= Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240206 header.b="n/3fcjFd"; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); 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 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. 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). 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. 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 ... take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#117029): https://edk2.groups.io/g/devel/message/117029 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] -=-=-=-=-=-=-=-=-=-=-=-