public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Yao, Jiewen" <jiewen.yao@intel.com>
Cc: Dionna Amalie Glaze <dionnaglaze@google.com>,
	 qinkun Bao <qinkun@google.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	 "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	 Ard Biesheuvel <ardb@kernel.org>,
	Peter Gonda <pgonda@google.com>,
	 James Bottomley <jejb@linux.ibm.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	 Michael Roth <michael.roth@amd.com>
Subject: Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR.
Date: Fri, 22 Mar 2024 09:52:04 +0100	[thread overview]
Message-ID: <u76teout4bwpg5yoklah6xfkrpcn4lw5nosw5lmph7sfjipqnz@gagzyh3xrkie> (raw)
In-Reply-To: <PH0PR11MB587959168F72B20E0AC836438C312@PH0PR11MB5879.namprd11.prod.outlook.com>

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]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2024-03-22  8:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-21 16:59 [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR qinkun Bao via groups.io
2024-03-21 17:46 ` Dionna Glaze via groups.io
2024-03-22  2:39   ` Yao, Jiewen
2024-03-22  8:52     ` Gerd Hoffmann [this message]
2024-03-22 14:56       ` Dionna Glaze via groups.io
2024-03-22 17:28         ` qinkun Bao via groups.io
2024-03-25 13:07         ` Mikko Ylinen
2024-03-25 15:28           ` Dionna Glaze via groups.io
2024-04-11  1:20             ` Yao, Jiewen
2024-04-11  6:23               ` qinkun Bao via groups.io
2024-04-11  6:52               ` Ard Biesheuvel
2024-04-11  8:07                 ` Gerd Hoffmann
2024-04-11  9:56                   ` Yao, Jiewen
2024-04-11 10:29                     ` Gerd Hoffmann
2024-04-11 10:33                       ` Ard Biesheuvel
2024-04-11 14:07                         ` Lendacky, Thomas via groups.io
2024-04-11 17:10                           ` Xiang, Qinglan
2024-04-13  9:36                 ` qinkun Bao via groups.io
2024-04-15 14:42                   ` Ard Biesheuvel
     [not found] ` <17C329C4A6D0CD18.8175@lists.confidentialcomputing.io>
     [not found]   ` <CAOjUGWcNedJ7iNjGCKL6qZeZo3aSt_8U5BN=9JUN2f2vjD+O4w@mail.gmail.com>
     [not found]     ` <CA+2DEOoc1Ckn2S-=57HiRsAd0W4YGRWVQQG-gOBR3Fc8nfX+Nw@mail.gmail.com>
2024-04-09 19:16       ` [edk2-devel] [linux-collab] [CCC][tac] " qinkun Bao via groups.io

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=u76teout4bwpg5yoklah6xfkrpcn4lw5nosw5lmph7sfjipqnz@gagzyh3xrkie \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox