[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOjUGWfgYoXBzUB8wFvO5LDq+=t7hAEksu0EA4Dc7FwbmUJp7A@mail.gmail.com>
Date: Wed, 11 Sep 2024 21:46:48 +0800
From: Qinkun Bao <qinkun@...gle.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: "Xing, Cedric" <cedric.xing@...el.com>, Jean-Philippe Brucker <jean-philippe@...aro.org>,
Dan Williams <dan.j.williams@...el.com>, Samuel Ortiz <sameo@...osinc.com>,
Lukas Wunner <lukas@...ner.de>, Dionna Amalie Glaze <dionnaglaze@...gle.com>,
Mikko Ylinen <mikko.ylinen@...ux.intel.com>,
Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>, linux-kernel@...r.kernel.org,
linux-coco@...ts.linux.dev, suzuki.poulose@....com, sami.mujawar@....com,
Chong Cai <chongc@...gle.com>
Subject: Re: [PATCH RFC 0/3] tsm: Unified Measurement Register ABI for TVMs
On Wed, Sep 11, 2024 at 8:06 PM James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
>
> On Tue, 2024-09-10 at 23:01 -0500, Xing, Cedric wrote:
> > On 9/10/2024 12:09 PM, Jean-Philippe Brucker wrote:
> > > Hi Cedric,
> > >
> > > On Sat, Sep 07, 2024 at 11:56:18PM -0500, Cedric Xing wrote:
> > > > Patch 2 introduces event log support for RTMRs, addressing the
> > > > fact that the standalone values of RTMRs, which represent the
> > > > cumulative digests of sequential events, are not fully
> > > > informative on their own.
> > >
> > > Would each event_log include the events that firmware wrote before
> > > Linux?
> >
> > No. The log format proposed here is textual and incompatible with
> > TCG2 log format.
> >
> > The proposed log format is based on the CoCo event log -
> > https://github.com/confidential-containers/guest-components/issues/495
> > .
>
> Given that AMD is planning to use the SVSM-vTPM for post launch
> measurements, not supporting TPMs in any form would make this Intel
> only on x86 and thus not very "unified". Microsoft also tends to do
> attestations partly via the vTPM in its L1 openHCL component (even for
> TDX) and thus would also have difficulty adopting this proposal.
>
Hi James,
I don't think the patch should be blocked for not supporting the
SVSM-vTPM and it is not an Intel only patch.
1. Not everyone prefers the SVSM-vTPM as it lacks the persistent
storage and does not comply with TCG's TPM specifications. TPM is not
just about the measurement.
Sealing and unsealing data is also a critical functionality for TPM.
Treating thenSVSM-vTPM as a TPM misleads users and disrupts existing
software based on TPMs.
The SVSM-vTPM is not TPM. Just like Javascript is not Java.
2. If our goal is to measure the boot chain and post-launch, the RTMR
is an effective and straightforward method.
We already support RTMR for TDX. For SNP, simulating the RTMRs in SVSM
is very simple while implementing the SVSM-vTPM needs a lot of changes.
The SVSM-vTPM significantly expands the TCB while offering limited
security value enhancements
compared to the RTMR.
3. RTMR as a technology has been adopted widely. It is not an Intel
only technology. The TDX CVMs on Google Cloud already support RTMRs.
The TDX CVMs [1] on
Alibaba Cloud supports RTMR as well. In terms of the attestation verifiers,
the token from Intel ITA [2] and Microsoft Attestation Service [3]
indicate they support RTMRs. The Ubuntu image [4] from Canonical
enables RTMR by default.
Link:
[1] https://www.alibabacloud.com/help/en/ecs/user-guide/build-a-tdx-confidential-computing-environment
[2] https://docs.trustauthority.intel.com/main/restapi/attestation-v2.html
[3] https://learn.microsoft.com/en-us/azure/attestation/attestation-token-examples
[4] https://ubuntu.com/blog/deploy-confidential-computing-intel-tdx-ubuntu-2404
Thanks,
Qinkun
Powered by blists - more mailing lists