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 [off-list ref] wrote:

quoted

On Fri, Mar 22, 2024 at 02:39:20AM +0000, Yao, Jiewen wrote:

quoted

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.

quoted

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.

quoted

Linux kernel appears to not have EFI_CC_MEASUREMENT_PROTOCOL support.

Since 6.9-rc1 we have it: ac93cbfc

quoted

quoted

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.

quoted

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