From: Qinkun Bao <qinkun@google.com>
To: Dionna Amalie Glaze <dionnaglaze@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
"Yao, Jiewen" <jiewen.yao@intel.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 10:28:41 -0700 [thread overview]
Message-ID: <CAOjUGWcdDX2Nt7hSJSvLZOBnGv318TXiKh8CdvutYr8L8H_6QA@mail.gmail.com> (raw)
In-Reply-To: <CAAH4kHbeGborxwDOzxeMbTjU4Xo79v-OVSHXYWQiJxg-yWQfWQ@mail.gmail.com>
On Fri, Mar 22, 2024 at 7:57 AM Dionna Amalie Glaze
<dionnaglaze@google.com> wrote:
>
> On Fri, Mar 22, 2024 at 1:52 AM Gerd Hoffmann <kraxel@redhat.com> 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.
> >
Thank you for the feedback. I believe it is the existing status even
without the patch.
Both EFI_CC_MEASUREMENT_PROTOCOL and EFI_TCG2_PROTOCOL
are exposed by TDVF when CC_MEASUREMENT_ENABLE is set to true even
without the patch. TDVF only measures with EFI_CC_MEASUREMENT_PROTOCOL
protocol. However, since both protocols exist, Shim and Grub2 measure
into both CCand TPM. In the guest, the user can access both the event log for
TPM andvRTMR. Some of the event logs for TPM are missing without the patch.
As Dionna mentioned (CVE-2021-42299), measuring into every device that
is available seems to be a safer choice. It's a mistake we've
concretely made in the past.
I am thinking your biggest concern is OS. Fortunately, there is no
accepted patch in the kernel that appears to have
EFI_CC_MEASUREMENT_PROTOCOL support. Once this
patch is accepted, we will work with the kernel community to recommend
the following code pattern "for device in measurement_devices:
device.Extend(bla)" for all guest components.
> > 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.
>
next prev parent reply other threads:[~2024-03-22 17:28 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
2024-03-22 14:56 ` Dionna Amalie Glaze
2024-03-22 17:28 ` Qinkun Bao [this message]
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=CAOjUGWcdDX2Nt7hSJSvLZOBnGv318TXiKh8CdvutYr8L8H_6QA@mail.gmail.com \
--to=qinkun@google.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=kraxel@redhat.com \
--cc=linux-coco@lists.linux.dev \
--cc=michael.roth@amd.com \
--cc=pgonda@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.