Re: [edk2-devel] [RFC PATCH] OvmfPkg/SecurityPkg: Add build option for coexistance of vTPM and RTMR.

["qinkun Bao via groups.io" <qinkun=google.com@groups.io>]

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.
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117132): https://edk2.groups.io/g/devel/message/117132
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]
-=-=-=-=-=-=-=-=-=-=-=-