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: [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
next prev parent 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 [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR qinkun Bao
2024-03-21 17:46 ` Dionna Amalie Glaze
2024-03-22 2:39 ` Yao, Jiewen
2024-03-22 8:52 ` Gerd Hoffmann [this message]
2024-03-22 14:56 ` Dionna Amalie Glaze
2024-03-22 17:28 ` Qinkun Bao
2024-03-25 13:07 ` Mikko Ylinen
2024-03-25 15:28 ` Dionna Amalie Glaze
2024-04-11 1:20 ` Yao, Jiewen
2024-04-11 6:23 ` Qinkun Bao
2024-04-11 6:52 ` [edk2-devel] " Ard Biesheuvel
2024-04-11 8:07 ` Gerd Hoffmann
2024-04-11 9:56 ` Yao, Jiewen
2024-04-11 10:29 ` kraxel
2024-04-11 10:33 ` Ard Biesheuvel
2024-04-11 14:07 ` Tom Lendacky
2024-04-11 17:10 ` Xiang, Qinglan
2024-04-13 9:36 ` Qinkun Bao
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 ` Fwd: [External] Re: [linux-collab] [CCC][tac] " Qinkun Bao
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-all 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=kraxel@redhat.com \
--cc=ardb@kernel.org \
--cc=devel@edk2.groups.io \
--cc=dionnaglaze@google.com \
--cc=erdemaktas@google.com \
--cc=jejb@linux.ibm.com \
--cc=jiewen.yao@intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=michael.roth@amd.com \
--cc=pgonda@google.com \
--cc=qinkun@google.com \
--cc=thomas.lendacky@amd.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.