From: Dionna Amalie Glaze <dionnaglaze@google.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Yao, Jiewen" <jiewen.yao@intel.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 07:56:53 -0700 [thread overview]
Message-ID: <CAAH4kHbeGborxwDOzxeMbTjU4Xo79v-OVSHXYWQiJxg-yWQfWQ@mail.gmail.com> (raw)
In-Reply-To: <u76teout4bwpg5yoklah6xfkrpcn4lw5nosw5lmph7sfjipqnz@gagzyh3xrkie>
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.
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 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
--
-Dionna Glaze, PhD (she/her)
next prev parent reply other threads:[~2024-03-22 14:57 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 [this message]
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=CAAH4kHbeGborxwDOzxeMbTjU4Xo79v-OVSHXYWQiJxg-yWQfWQ@mail.gmail.com \
--to=dionnaglaze@google.com \
--cc=ardb@kernel.org \
--cc=devel@edk2.groups.io \
--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=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.