From: Dan Williams <dan.j.williams@intel.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>,
Dan Middleton <dan.middleton@linux.intel.com>,
Dionna Amalie Glaze <dionnaglaze@google.com>,
Dave Hansen <dave.hansen@intel.com>
Cc: "Xing, Cedric" <cedric.xing@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
<x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
<linux-kernel@vger.kernel.org>, <linux-coco@lists.linux.dev>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>
Subject: Re: [PATCH 0/4] tsm: Unified Measurement Register ABI for TVMs
Date: Wed, 19 Feb 2025 15:02:55 -0800 [thread overview]
Message-ID: <67b6631fc7054_2d2c294f1@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <6e773bfd1275d4f8c7df1ca65e22ec42eba12a8e.camel@HansenPartnership.com>
James Bottomley wrote:
[..]
> What I still don't get is this. The difference between RTMRs and the
> subset of TPM functionality that also provides it is non-existent.
> It's like a distinction without a difference. If the SVSM authors had
> written for a pure RTMR implementation (just usng a CRB API) would that
> have made a difference?
That is an interesting hypothetical, "would things be different if the
authors, that were forced by SEV-SNP architectural necessity to push
runtime measurement functionality into an SVSM layer exclusively, had
considered that some architectures would include runtime measurement
functionality in the CVM technology directly?". I do not think it helps
because that presupposes that vTPM for these other architectures already
exists.
When I look at the proposed solutions for TDX-vTPM based on service VMs
and other complications brought on by architectural differences between
TDX and SEV-SNP, and compare that to a potential vTPM that wraps RTMR I
see a net reduction in complexity. In other words, a path to a
cross-architecture RTMR-backed vTPM without requiring SVSM and
approximation of the VMPL mechanism. It follows that userspace, not the
kernel, needs to wrap architectural RTMR differences to build that vTPM.
So to me the question is less "RTMR vs TPM" and more about vTPM
implementation choice where RTMR-backed and SVSM-based vTPM solutions
are not mutually exclusive.
For the kernel this mean leaking architecture specific RTMR details into
its ABI and punting the vTPM interface problem to userspace. It also
means that software, in some cases, could forgo vTPM and use raw RTMR.
However, I do not think that ultimately fragments the ecosystem. TPM
momentum and portability concerns limits how far raw RTMR usage will
extend, but in the meantime for use cases that "don't want to have to
depend on the vTPM", like the one Dionna mentioned, are enabled.
If those use case ultimately melt away and transition to vTPM (whether
RTMR backed or SVSM backed), great. If those use cases persist then that
is also a useful system evolution signal from the ecosystem.
next prev parent reply other threads:[~2025-02-19 23:03 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 2:23 [PATCH 0/4] tsm: Unified Measurement Register ABI for TVMs Cedric Xing
2025-02-13 2:23 ` [PATCH 1/4] tsm: Add TVM Measurement Register support Cedric Xing
2025-02-14 0:55 ` kernel test robot
2025-02-17 0:17 ` Huang, Kai
2025-02-17 10:44 ` Huang, Kai
2025-02-17 20:57 ` Xing, Cedric
2025-02-18 9:14 ` Huang, Kai
2025-02-18 18:13 ` Xing, Cedric
2025-02-18 1:10 ` Sathyanarayanan Kuppuswamy
2025-02-20 1:01 ` Xing, Cedric
2025-02-13 2:23 ` [PATCH 2/4] tsm: Add TSM measurement sample code Cedric Xing
2025-02-13 2:23 ` [PATCH 3/4] x86/tdx: Add tdx_mcall_rtmr_extend() interface Cedric Xing
2025-02-17 0:40 ` Huang, Kai
2025-02-17 20:58 ` Xing, Cedric
2025-02-17 21:39 ` Sathyanarayanan Kuppuswamy
2025-02-13 2:23 ` [PATCH 4/4] x86/tdx: Expose TDX MRs through TSM sysfs interface Cedric Xing
2025-02-13 4:50 ` [PATCH 0/4] tsm: Unified Measurement Register ABI for TVMs Dave Hansen
2025-02-13 16:21 ` Xing, Cedric
2025-02-13 16:58 ` Dave Hansen
2025-02-13 21:50 ` Xing, Cedric
2025-02-13 23:19 ` Dave Hansen
2025-02-14 16:19 ` Xing, Cedric
2025-02-14 16:26 ` Dave Hansen
2025-02-14 21:59 ` Xing, Cedric
2025-02-18 16:25 ` Dan Middleton
2025-02-18 16:57 ` Dave Hansen
2025-02-18 23:57 ` Dionna Amalie Glaze
2025-02-19 0:41 ` Dave Hansen
2025-02-19 3:21 ` Dionna Amalie Glaze
2025-02-19 13:29 ` James Bottomley
2025-02-19 15:24 ` Dan Middleton
2025-02-19 20:53 ` James Bottomley
2025-02-19 22:25 ` Xing, Cedric
2025-02-19 23:02 ` Dan Williams [this message]
2025-05-02 1:45 ` Dan Williams
2025-02-18 14:49 ` Mikko Ylinen
2025-02-19 4:04 ` Xing, Cedric
2025-02-19 11:31 ` Huang, Kai
2025-02-20 4:37 ` Xing, Cedric
2025-02-19 14:03 ` Mikko Ylinen
2025-02-20 5:07 ` Xing, Cedric
2025-02-18 1:10 ` Sathyanarayanan Kuppuswamy
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=67b6631fc7054_2d2c294f1@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=bp@alien8.de \
--cc=cedric.xing@intel.com \
--cc=dan.middleton@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox