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

[Mikko Ylinen <mikko.ylinen@linux.intel.com>]

On Fri, Mar 22, 2024 at 07:56:53AM -0700, Dionna Amalie Glaze 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.
> >
> > 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.
> 
> >
> > 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).
> >
> 
> Interesting. Thanks for this report. We'll push for the changed
> semantics here if the spec is indeed changed, and request partner
> distros in the CCC to include the updated systemd-boot.

FWIW, my RTMRs patch to systemd was merged quite recently so it's not
included in any systemd release yet. (It was mainly implemented for the
UKI case that allows TDVF to boot a UKI image directly and then have the
image sections measured separately.)

> I think that since the current boot integrity story stops at PCR9, we
> have time to update this component before the attestation method
> evolves to support a less special-purpose system composition.
> 
> > Linux kernel appears to not have EFI_CC_MEASUREMENT_PROTOCOL support.
> >

Since 6.9-rc1 we have it: ac93cbfc

> > > 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.
> >
> 
> An ephemeral TPM that Coconut-svsm offers is qualitatively different
> than the persistent TPMs in CSPs today. Users of Confidential VMs all
> have different threat models that allow for trusting a CSP-managed
> vTPM for sealing keys but not for trusting unencrypted data in use.
> The boot stack attestation story will not be fully resolved for a long
> while, and a smooth transition is better than a jarring one.
> 
> > 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 ...
> >
> 
> I agree, but it does mean we have to change the event log composition
> to describe the configured measurement services like described above.
> I think a static Pcd is okay to begin with. The idea for tracking
> these qualities is through software supply chain endorsements.
> Eventually that would look like the proposed in-toto's SCAI [1] but
> until then we'd have a bespoke format that we document and integrate
> with in an attestation verification service.
> 
> [1] https://arxiv.org/pdf/2210.05813.pdf

-- Regards, Mikko


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