NOTE: This patch series introduces the Measurement Register (MR) ABI, and
is a continuation of the RFC series on the same topic [1].

This patch series adds a unified interface to TSM core for confidential
computing (CC) guest drivers to provide access to measurement registers
(MRs), which are essential for relying parties (RPs) to verify the
integrity of the computing environment. The interface is structured around
`struct tsm_measurement`, which holds an array of `struct
tsm_measurement_register` and includes operations for reading and updating
MRs.

Each `struct tsm_measurement_register` features a `mr_flags` member that
indicates the MR's properties, such as *Readable* (`TSM_MR_F_R`),
*Extensible* (`TSM_MR_F_X`), etc. Please refer to Patch 1 in this series
for more details. Patch 2 adds a sample module to demonstrate how to define
and implement MRs in a CC guest driver. The last patches add TDX MR support
to the TDX Guest driver.

MRs are made accessible to applications through a directory tree (rooted at
`/sys/kernel/tsm`). An MR could be presented as either a file containing
its value, or a directory containing the file `digest` under a subdirectory
of the same name as the hash algorithm. By default, an MR will be presented
as a directory unless `TSM_MR_F_F` is set in `mr_flags`.

[1]: https://lore.kernel.org/linux-coco/20241210-tsm-rtmr-v3-0-5997d4dbda73@intel.com/

Signed-off-by: Cedric Xing <cedric.xing@intel.com>
---
Cedric Xing (3):
      tsm: Add TVM Measurement Register support
      tsm: Add TSM measurement sample code
      x86/tdx: Expose TDX MRs through TSM sysfs interface

Kuppuswamy Sathyanarayanan (1):
      x86/tdx: Add tdx_mcall_rtmr_extend() interface

 Documentation/ABI/testing/sysfs-kernel-tsm |  20 ++
 MAINTAINERS                                |   3 +-
 arch/x86/coco/tdx/tdx.c                    |  36 +++
 arch/x86/include/asm/shared/tdx.h          |   1 +
 arch/x86/include/asm/tdx.h                 |   2 +
 drivers/virt/coco/Kconfig                  |   3 +-
 drivers/virt/coco/Makefile                 |   2 +
 drivers/virt/coco/tdx-guest/Kconfig        |  15 ++
 drivers/virt/coco/tdx-guest/tdx-guest.c    | 119 +++++++++
 drivers/virt/coco/{tsm.c => tsm-core.c}    |   6 +-
 drivers/virt/coco/tsm-mr.c                 | 375 +++++++++++++++++++++++++++++
 include/linux/tsm.h                        |  64 +++++
 samples/Kconfig                            |  10 +
 samples/Makefile                           |   1 +
 samples/tsm/Makefile                       |   2 +
 samples/tsm/tsm_mr_sample.c                | 107 ++++++++
 16 files changed, 763 insertions(+), 3 deletions(-)
---
base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3
change-id: 20250209-tdx-rtmr-255479667146

Best regards,
-- 
Cedric Xing <cedric.xing@intel.com>

On 2/12/25 6:23 PM, Cedric Xing wrote:
> NOTE: This patch series introduces the Measurement Register (MR) ABI, and
> is a continuation of the RFC series on the same topic [1].
>
> This patch series adds a unified interface to TSM core for confidential
> computing (CC) guest drivers to provide access to measurement registers
> (MRs), which are essential for relying parties (RPs) to verify the
> integrity of the computing environment. The interface is structured around

I recommend adding information about possible use cases and how end
users might use it here.

> `struct tsm_measurement`, which holds an array of `struct
> tsm_measurement_register` and includes operations for reading and updating
> MRs.
>
> Each `struct tsm_measurement_register` features a `mr_flags` member that
> indicates the MR's properties, such as *Readable* (`TSM_MR_F_R`),
> *Extensible* (`TSM_MR_F_X`), etc. Please refer to Patch 1 in this series
> for more details. Patch 2 adds a sample module to demonstrate how to define
> and implement MRs in a CC guest driver. The last patches add TDX MR support
> to the TDX Guest driver.
>
> MRs are made accessible to applications through a directory tree (rooted at
> `/sys/kernel/tsm`). An MR could be presented as either a file containing
> its value, or a directory containing the file `digest` under a subdirectory
> of the same name as the hash algorithm. By default, an MR will be presented
> as a directory unless `TSM_MR_F_F` is set in `mr_flags`.
>
> [1]:https://lore.kernel.org/linux-coco/20241210-tsm-rtmr-v3-0-5997d4dbda73@intel.com/

I know that this patch set does not support event log extension for RTMR 
extend.
May be you can add some info about why we cannot support it now and any 
issues
with not supporting it now.

> Signed-off-by: Cedric Xing<cedric.xing@intel.com>
> ---
> Cedric Xing (3):
>        tsm: Add TVM Measurement Register support
>        tsm: Add TSM measurement sample code
>        x86/tdx: Expose TDX MRs through TSM sysfs interface
>
> Kuppuswamy Sathyanarayanan (1):
>        x86/tdx: Add tdx_mcall_rtmr_extend() interface
>
>   Documentation/ABI/testing/sysfs-kernel-tsm |  20 ++
>   MAINTAINERS                                |   3 +-
>   arch/x86/coco/tdx/tdx.c                    |  36 +++
>   arch/x86/include/asm/shared/tdx.h          |   1 +
>   arch/x86/include/asm/tdx.h                 |   2 +
>   drivers/virt/coco/Kconfig                  |   3 +-
>   drivers/virt/coco/Makefile                 |   2 +
>   drivers/virt/coco/tdx-guest/Kconfig        |  15 ++
>   drivers/virt/coco/tdx-guest/tdx-guest.c    | 119 +++++++++
>   drivers/virt/coco/{tsm.c => tsm-core.c}    |   6 +-
>   drivers/virt/coco/tsm-mr.c                 | 375 +++++++++++++++++++++++++++++
>   include/linux/tsm.h                        |  64 +++++
>   samples/Kconfig                            |  10 +
>   samples/Makefile                           |   1 +
>   samples/tsm/Makefile                       |   2 +
>   samples/tsm/tsm_mr_sample.c                | 107 ++++++++
>   16 files changed, 763 insertions(+), 3 deletions(-)
> ---
> base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3
> change-id: 20250209-tdx-rtmr-255479667146
>
> Best regards,

-- 
Sathyanarayanan Kuppuswamy
Linux Kernel Developer

On 2/12/25 18:23, Cedric Xing wrote:
> NOTE: This patch series introduces the Measurement Register (MR) ABI, and
> is a continuation of the RFC series on the same topic [1].

Hi Cedric,

Could you please explain how the benefits of this series are helpful to
end users?

On 2/12/2025 10:50 PM, Dave Hansen wrote:
> On 2/12/25 18:23, Cedric Xing wrote:
>> NOTE: This patch series introduces the Measurement Register (MR) ABI, and
>> is a continuation of the RFC series on the same topic [1].
> 
> Hi Cedric,
> 
> Could you please explain how the benefits of this series are helpful to
> end users?

This series exposes MRs as sysfs attributes, allowing end users to 
access them effortlessly without needing to write any code. This 
simplifies the process of debugging and diagnosing measurement-related 
issues. Additionally, it makes the CC architecture more intuitive for 
newcomers.

On 2/13/25 08:21, Xing, Cedric wrote:
> On 2/12/2025 10:50 PM, Dave Hansen wrote:
>> On 2/12/25 18:23, Cedric Xing wrote:
>>> NOTE: This patch series introduces the Measurement Register (MR) ABI,
>>> and
>>> is a continuation of the RFC series on the same topic [1].
>>
>> Could you please explain how the benefits of this series are helpful to
>> end users?
> 
> This series exposes MRs as sysfs attributes, allowing end users to
> access them effortlessly without needing to write any code. This
> simplifies the process of debugging and diagnosing measurement-related
> issues. Additionally, it makes the CC architecture more intuitive for
> newcomers.

Wait a sec, so there's already ABI for manipulating these? This just
adds a parallel sysfs interface to the existing ABI?

Also, you're saying that users don't need to write any code, but then
provide... sample code. That's unexpected.

Oh, and you seem to have forgotten to attach the sysfs ABI documentation
patch to the series. You did write the required documentation, right? ;)

On 2/13/2025 10:58 AM, Dave Hansen wrote:
> On 2/13/25 08:21, Xing, Cedric wrote:
>> On 2/12/2025 10:50 PM, Dave Hansen wrote:
>>> On 2/12/25 18:23, Cedric Xing wrote:
>>>> NOTE: This patch series introduces the Measurement Register (MR) ABI,
>>>> and
>>>> is a continuation of the RFC series on the same topic [1].
>>>
>>> Could you please explain how the benefits of this series are helpful to
>>> end users?
>>
>> This series exposes MRs as sysfs attributes, allowing end users to
>> access them effortlessly without needing to write any code. This
>> simplifies the process of debugging and diagnosing measurement-related
>> issues. Additionally, it makes the CC architecture more intuitive for
>> newcomers.
> 
> Wait a sec, so there's already ABI for manipulating these? This just
> adds a parallel sysfs interface to the existing ABI?
> 
No, this is new. There's no existing ABI for accessing measurement 
registers from within a TVM (TEE VM). Currently, on TDX for example, 
reading TDX measurement registers (MRs) must be done by getting a TD 
quote. And there's no way to extend any RTMRs. Therefore, it would be 
much easier end users to debug/diagnose measurement related issues 
(which would almost always require reading MRs) with this patch.

> Also, you're saying that users don't need to write any code, but then
> provide... sample code. That's unexpected.
> 
The sample code is to demo how to expose MRs from a CC guest driver, but 
not for end users to access those MRs.

> Oh, and you seem to have forgotten to attach the sysfs ABI documentation
> patch to the series. You did write the required documentation, right? ;)
Documentation/ABI/testing/sysfs-kernel-tsm (new file added by patch 1) 
contains a description on the attributes added by the patch.

On Thu, Feb 13, 2025 at 03:50:19PM -0600, Xing, Cedric wrote:
> On 2/13/2025 10:58 AM, Dave Hansen wrote:
> > On 2/13/25 08:21, Xing, Cedric wrote:
> > > On 2/12/2025 10:50 PM, Dave Hansen wrote:
> > > > On 2/12/25 18:23, Cedric Xing wrote:
> > > > > NOTE: This patch series introduces the Measurement Register (MR) ABI,
> > > > > and
> > > > > is a continuation of the RFC series on the same topic [1].
> > > > 
> > > > Could you please explain how the benefits of this series are helpful to
> > > > end users?
> > > 
> > > This series exposes MRs as sysfs attributes, allowing end users to
> > > access them effortlessly without needing to write any code. This
> > > simplifies the process of debugging and diagnosing measurement-related
> > > issues. Additionally, it makes the CC architecture more intuitive for
> > > newcomers.
> > 
> > Wait a sec, so there's already ABI for manipulating these? This just
> > adds a parallel sysfs interface to the existing ABI?
> > 
> No, this is new. There's no existing ABI for accessing measurement registers
> from within a TVM (TEE VM). Currently, on TDX for example, reading TDX
> measurement registers (MRs) must be done by getting a TD quote. And there's
> no way to extend any RTMRs. Therefore, it would be much easier end users to

TD reports *are* available through the tdx_guest ioctl so there's overlap
with the suggested reportdata/report0 entries at least. Since configfs-tsm
provides the generic transport for TVM reports, the best option to make report0
available is through configfs-tsm reports.

The use case on MRCONFIGID mentioned later in this thread does not depend
on this series. It's easy for the user-space to interprete the full report
to find MRCONFIGID or any other register value (the same is true for HOSTDATA
on SNP).

The question here is whether there's any real benefit for the kernel to
expose the provider specific report details through sysfs or could we focus on
the RTMR extend capability only.

-- 
Regards, Mikko

On 2/18/2025 8:49 AM, Mikko Ylinen wrote:
> On Thu, Feb 13, 2025 at 03:50:19PM -0600, Xing, Cedric wrote:
>> On 2/13/2025 10:58 AM, Dave Hansen wrote:
>>> On 2/13/25 08:21, Xing, Cedric wrote:
>>>> On 2/12/2025 10:50 PM, Dave Hansen wrote:
>>>>> On 2/12/25 18:23, Cedric Xing wrote:
>>>>>> NOTE: This patch series introduces the Measurement Register (MR) ABI,
>>>>>> and
>>>>>> is a continuation of the RFC series on the same topic [1].
>>>>>
>>>>> Could you please explain how the benefits of this series are helpful to
>>>>> end users?
>>>>
>>>> This series exposes MRs as sysfs attributes, allowing end users to
>>>> access them effortlessly without needing to write any code. This
>>>> simplifies the process of debugging and diagnosing measurement-related
>>>> issues. Additionally, it makes the CC architecture more intuitive for
>>>> newcomers.
>>>
>>> Wait a sec, so there's already ABI for manipulating these? This just
>>> adds a parallel sysfs interface to the existing ABI?
>>>
>> No, this is new. There's no existing ABI for accessing measurement registers
>> from within a TVM (TEE VM). Currently, on TDX for example, reading TDX
>> measurement registers (MRs) must be done by getting a TD quote. And there's
>> no way to extend any RTMRs. Therefore, it would be much easier end users to
> 
> TD reports *are* available through the tdx_guest ioctl so there's overlap
> with the suggested reportdata/report0 entries at least. Since configfs-tsm
> provides the generic transport for TVM reports, the best option to make report0
> available is through configfs-tsm reports.
> 
Given the purpose of TSM, I once thought this TDX_CMD_GET_REPORT0 ioctl 
of /dev/tdx_guest had been deprecated but I was wrong.

However, unlocked_ioctl is the only fops remaining on /dev/tdx_guest and 
TDX_CMD_GET_REPORT0 is the only command supported. It might soon be time 
to deprecate this interface.

> The use case on MRCONFIGID mentioned later in this thread does not depend
> on this series. It's easy for the user-space to interprete the full report
> to find MRCONFIGID or any other register value (the same is true for HOSTDATA
> on SNP).
> 
Yes, parsing the full report will always be an option. But reading 
static MRs like MRCONDFIGID or HOSTDATA from sysfs attributes will be 
way more convenient.

Additionally, this sysfs interface is more friendly to newcomers, as 
everyone can tell what MRs are available from the directory tree 
structure, rather than studying processor manuals.

> The question here is whether there's any real benefit for the kernel to
> expose the provider specific report details through sysfs or could we focus on
> the RTMR extend capability only.
> 
Again, parsing the full report is always an alternative for reading any 
MRs from the underlying arch. But it's much more convenient to read them 
from files, which I believe is a REAL benefit.

Or can we flip the question around and ask: is there any real benefit 
NOT to allow reading MRs as files and force users and applications to go 
through an arch specific IOCTL interface?

On Tue, Feb 18, 2025 at 10:04:19PM -0600, Xing, Cedric wrote:
> On 2/18/2025 8:49 AM, Mikko Ylinen wrote:
> > On Thu, Feb 13, 2025 at 03:50:19PM -0600, Xing, Cedric wrote:
> > > On 2/13/2025 10:58 AM, Dave Hansen wrote:
> > > > On 2/13/25 08:21, Xing, Cedric wrote:
> > > > > On 2/12/2025 10:50 PM, Dave Hansen wrote:
> > > > > > On 2/12/25 18:23, Cedric Xing wrote:
> > > > > > > NOTE: This patch series introduces the Measurement Register (MR) ABI,
> > > > > > > and
> > > > > > > is a continuation of the RFC series on the same topic [1].
> > > > > > 
> > > > > > Could you please explain how the benefits of this series are helpful to
> > > > > > end users?
> > > > > 
> > > > > This series exposes MRs as sysfs attributes, allowing end users to
> > > > > access them effortlessly without needing to write any code. This
> > > > > simplifies the process of debugging and diagnosing measurement-related
> > > > > issues. Additionally, it makes the CC architecture more intuitive for
> > > > > newcomers.
> > > > 
> > > > Wait a sec, so there's already ABI for manipulating these? This just
> > > > adds a parallel sysfs interface to the existing ABI?
> > > > 
> > > No, this is new. There's no existing ABI for accessing measurement registers
> > > from within a TVM (TEE VM). Currently, on TDX for example, reading TDX
> > > measurement registers (MRs) must be done by getting a TD quote. And there's
> > > no way to extend any RTMRs. Therefore, it would be much easier end users to
> > 
> > TD reports *are* available through the tdx_guest ioctl so there's overlap
> > with the suggested reportdata/report0 entries at least. Since configfs-tsm
> > provides the generic transport for TVM reports, the best option to make report0
> > available is through configfs-tsm reports.
> > 
> Given the purpose of TSM, I once thought this TDX_CMD_GET_REPORT0 ioctl of
> /dev/tdx_guest had been deprecated but I was wrong.
> 
> However, unlocked_ioctl is the only fops remaining on /dev/tdx_guest and
> TDX_CMD_GET_REPORT0 is the only command supported. It might soon be time to
> deprecate this interface.

Once an alternative is available but it's still in use because of this 
use case (i.e., read registers from a TD report). AFAUI, SEV has its
reports available through configfs-tsm reports so it'd be a good fit here too.

Obviously, if the registers get exposed through this series, the use case
can be covered but full TD report is still good to keep available.

> 
> > The use case on MRCONFIGID mentioned later in this thread does not depend
> > on this series. It's easy for the user-space to interprete the full report
> > to find MRCONFIGID or any other register value (the same is true for HOSTDATA
> > on SNP).
> > 
> Yes, parsing the full report will always be an option. But reading static
> MRs like MRCONDFIGID or HOSTDATA from sysfs attributes will be way more
> convenient.
> 
> Additionally, this sysfs interface is more friendly to newcomers, as
> everyone can tell what MRs are available from the directory tree structure,
> rather than studying processor manuals.
> 
> > The question here is whether there's any real benefit for the kernel to
> > expose the provider specific report details through sysfs or could we focus on
> > the RTMR extend capability only.
> > 
> Again, parsing the full report is always an alternative for reading any MRs
> from the underlying arch. But it's much more convenient to read them from
> files, which I believe is a REAL benefit.
> 
> Or can we flip the question around and ask: is there any real benefit NOT to
> allow reading MRs as files and force users and applications to go through an
> arch specific IOCTL interface?

FWIW, I'm not thinking about IOCTLs here but configfs-tsm reports: a
single read gives you all registers as specified by the report without
having to add anything to the kernel ABI.

-- 
Regards, Mikko

On 2/19/2025 8:03 AM, Mikko Ylinen wrote:
> On Tue, Feb 18, 2025 at 10:04:19PM -0600, Xing, Cedric wrote:
>> On 2/18/2025 8:49 AM, Mikko Ylinen wrote:
>>> On Thu, Feb 13, 2025 at 03:50:19PM -0600, Xing, Cedric wrote:
>>>> On 2/13/2025 10:58 AM, Dave Hansen wrote:
>>>>> On 2/13/25 08:21, Xing, Cedric wrote:
>>>>>> On 2/12/2025 10:50 PM, Dave Hansen wrote:
>>>>>>> On 2/12/25 18:23, Cedric Xing wrote:
>>>>>>>> NOTE: This patch series introduces the Measurement Register (MR) ABI,
>>>>>>>> and
>>>>>>>> is a continuation of the RFC series on the same topic [1].
>>>>>>>
>>>>>>> Could you please explain how the benefits of this series are helpful to
>>>>>>> end users?
>>>>>>
>>>>>> This series exposes MRs as sysfs attributes, allowing end users to
>>>>>> access them effortlessly without needing to write any code. This
>>>>>> simplifies the process of debugging and diagnosing measurement-related
>>>>>> issues. Additionally, it makes the CC architecture more intuitive for
>>>>>> newcomers.
>>>>>
>>>>> Wait a sec, so there's already ABI for manipulating these? This just
>>>>> adds a parallel sysfs interface to the existing ABI?
>>>>>
>>>> No, this is new. There's no existing ABI for accessing measurement registers
>>>> from within a TVM (TEE VM). Currently, on TDX for example, reading TDX
>>>> measurement registers (MRs) must be done by getting a TD quote. And there's
>>>> no way to extend any RTMRs. Therefore, it would be much easier end users to
>>>
>>> TD reports *are* available through the tdx_guest ioctl so there's overlap
>>> with the suggested reportdata/report0 entries at least. Since configfs-tsm
>>> provides the generic transport for TVM reports, the best option to make report0
>>> available is through configfs-tsm reports.
>>>
>> Given the purpose of TSM, I once thought this TDX_CMD_GET_REPORT0 ioctl of
>> /dev/tdx_guest had been deprecated but I was wrong.
>>
>> However, unlocked_ioctl is the only fops remaining on /dev/tdx_guest and
>> TDX_CMD_GET_REPORT0 is the only command supported. It might soon be time to
>> deprecate this interface.
> 
> Once an alternative is available but it's still in use because of this
> use case (i.e., read registers from a TD report). AFAUI, SEV has its
> reports available through configfs-tsm reports so it'd be a good fit here too.
> 
I think every CC arch should have a presence in configfs-tsm for 
generating remotely verifiable reports. This patch series offers 
read/extend functionality to MRs. The overlap here is that any reports 
should include the values of all MRs. However, obtaining a report may 
not be the only way to read MRs. For example, TPM supports commands for 
reading PCRs without attesting to their values. The read functionality 
is definitely a convenience to applications, and helps performance, and 
can also help educating developers. The configfs-tsm report interface 
will work for sure but I don't how it could be as a good fit as this 
sysfs interface.

> Obviously, if the registers get exposed through this series, the use case
> can be covered but full TD report is still good to keep available.
> 
With this series, the full TD report can be requested by writing to 
`reportdata` followed by reading from `report0`.

>>
>>> The use case on MRCONFIGID mentioned later in this thread does not depend
>>> on this series. It's easy for the user-space to interprete the full report
>>> to find MRCONFIGID or any other register value (the same is true for HOSTDATA
>>> on SNP).
>>>
>> Yes, parsing the full report will always be an option. But reading static
>> MRs like MRCONDFIGID or HOSTDATA from sysfs attributes will be way more
>> convenient.
>>
>> Additionally, this sysfs interface is more friendly to newcomers, as
>> everyone can tell what MRs are available from the directory tree structure,
>> rather than studying processor manuals.
>>
>>> The question here is whether there's any real benefit for the kernel to
>>> expose the provider specific report details through sysfs or could we focus on
>>> the RTMR extend capability only.
>>>
>> Again, parsing the full report is always an alternative for reading any MRs
>> from the underlying arch. But it's much more convenient to read them from
>> files, which I believe is a REAL benefit.
>>
>> Or can we flip the question around and ask: is there any real benefit NOT to
>> allow reading MRs as files and force users and applications to go through an
>> arch specific IOCTL interface?
> 
> FWIW, I'm not thinking about IOCTLs here but configfs-tsm reports: a
> single read gives you all registers as specified by the report without
> having to add anything to the kernel ABI.
> 
Guess through configfs-tsm you'd have to select the service provider 
first. In contrast, it'd take only a single read from `report0` to get 
the full report through this series. Moreover, it is table driven, so 
these `report0`/`reportdata` attributes add ZERO code and take only 2 
table entries (<100 bytes) to implement on TDX. I'm not sure if adding a 
local report provider to configfs-tsm can be any simpler.

On Tue, 2025-02-18 at 22:04 -0600, Xing, Cedric wrote:
> On 2/18/2025 8:49 AM, Mikko Ylinen wrote:
> > On Thu, Feb 13, 2025 at 03:50:19PM -0600, Xing, Cedric wrote:
> > > On 2/13/2025 10:58 AM, Dave Hansen wrote:
> > > > On 2/13/25 08:21, Xing, Cedric wrote:
> > > > > On 2/12/2025 10:50 PM, Dave Hansen wrote:
> > > > > > On 2/12/25 18:23, Cedric Xing wrote:
> > > > > > > NOTE: This patch series introduces the Measurement Register (MR) ABI,
> > > > > > > and
> > > > > > > is a continuation of the RFC series on the same topic [1].
> > > > > > 
> > > > > > Could you please explain how the benefits of this series are helpful to
> > > > > > end users?
> > > > > 
> > > > > This series exposes MRs as sysfs attributes, allowing end users to
> > > > > access them effortlessly without needing to write any code. This
> > > > > simplifies the process of debugging and diagnosing measurement-related
> > > > > issues. Additionally, it makes the CC architecture more intuitive for
> > > > > newcomers.
> > > > 
> > > > Wait a sec, so there's already ABI for manipulating these? This just
> > > > adds a parallel sysfs interface to the existing ABI?
> > > > 
> > > No, this is new. There's no existing ABI for accessing measurement registers
> > > from within a TVM (TEE VM). Currently, on TDX for example, reading TDX
> > > measurement registers (MRs) must be done by getting a TD quote. And there's
> > > no way to extend any RTMRs. Therefore, it would be much easier end users to
> > 
> > TD reports *are* available through the tdx_guest ioctl so there's overlap
> > with the suggested reportdata/report0 entries at least. Since configfs-tsm
> > provides the generic transport for TVM reports, the best option to make report0
> > available is through configfs-tsm reports.
> > 
> Given the purpose of TSM, I once thought this TDX_CMD_GET_REPORT0 ioctl 
> of /dev/tdx_guest had been deprecated but I was wrong.
> 
> However, unlocked_ioctl is the only fops remaining on /dev/tdx_guest and 
> TDX_CMD_GET_REPORT0 is the only command supported. It might soon be time 
> to deprecate this interface.

I agree.

> 
> > The use case on MRCONFIGID mentioned later in this thread does not depend
> > on this series. It's easy for the user-space to interprete the full report
> > to find MRCONFIGID or any other register value (the same is true for HOSTDATA
> > on SNP).
> > 
> Yes, parsing the full report will always be an option. But reading 
> static MRs like MRCONDFIGID or HOSTDATA from sysfs attributes will be 
> way more convenient.

But, theoretically, you cannot really trust what your read from the kernel for
such *single field*, because to truly get verified you will need to get the full
report anyway.

> 
> Additionally, this sysfs interface is more friendly to newcomers, as 
> everyone can tell what MRs are available from the directory tree 
> structure, rather than studying processor manuals.
> 
> > The question here is whether there's any real benefit for the kernel to
> > expose the provider specific report details through sysfs or could we focus on
> > the RTMR extend capability only.
> > 
> Again, parsing the full report is always an alternative for reading any 
> MRs from the underlying arch. But it's much more convenient to read them 
> from files, which I believe is a REAL benefit.
> 
> Or can we flip the question around and ask: is there any real benefit 
> NOT to allow reading MRs as files and force users and applications to go 
> through an arch specific IOCTL interface?
> 

As above, I am not convinced that *reading* MRs alone is that useful.  What you
need is a unified way to *extend* those MRs.

And yeah I agree extending arch-specific IOCTL to support extending any runtime
MR isn't a good idea. 

On 2/19/2025 5:31 AM, Huang, Kai wrote:
> On Tue, 2025-02-18 at 22:04 -0600, Xing, Cedric wrote:
>> On 2/18/2025 8:49 AM, Mikko Ylinen wrote:
>>> On Thu, Feb 13, 2025 at 03:50:19PM -0600, Xing, Cedric wrote:
>>>> On 2/13/2025 10:58 AM, Dave Hansen wrote:
>>>>> On 2/13/25 08:21, Xing, Cedric wrote:
>>>>>> On 2/12/2025 10:50 PM, Dave Hansen wrote:
>>>>>>> On 2/12/25 18:23, Cedric Xing wrote:
>>>>>>>> NOTE: This patch series introduces the Measurement Register (MR) ABI,
>>>>>>>> and
>>>>>>>> is a continuation of the RFC series on the same topic [1].
>>>>>>>
>>>>>>> Could you please explain how the benefits of this series are helpful to
>>>>>>> end users?
>>>>>>
>>>>>> This series exposes MRs as sysfs attributes, allowing end users to
>>>>>> access them effortlessly without needing to write any code. This
>>>>>> simplifies the process of debugging and diagnosing measurement-related
>>>>>> issues. Additionally, it makes the CC architecture more intuitive for
>>>>>> newcomers.
>>>>>
>>>>> Wait a sec, so there's already ABI for manipulating these? This just
>>>>> adds a parallel sysfs interface to the existing ABI?
>>>>>
>>>> No, this is new. There's no existing ABI for accessing measurement registers
>>>> from within a TVM (TEE VM). Currently, on TDX for example, reading TDX
>>>> measurement registers (MRs) must be done by getting a TD quote. And there's
>>>> no way to extend any RTMRs. Therefore, it would be much easier end users to
>>>
>>> TD reports *are* available through the tdx_guest ioctl so there's overlap
>>> with the suggested reportdata/report0 entries at least. Since configfs-tsm
>>> provides the generic transport for TVM reports, the best option to make report0
>>> available is through configfs-tsm reports.
>>>
>> Given the purpose of TSM, I once thought this TDX_CMD_GET_REPORT0 ioctl
>> of /dev/tdx_guest had been deprecated but I was wrong.
>>
>> However, unlocked_ioctl is the only fops remaining on /dev/tdx_guest and
>> TDX_CMD_GET_REPORT0 is the only command supported. It might soon be time
>> to deprecate this interface.
> 
> I agree.
> 
>>
>>> The use case on MRCONFIGID mentioned later in this thread does not depend
>>> on this series. It's easy for the user-space to interprete the full report
>>> to find MRCONFIGID or any other register value (the same is true for HOSTDATA
>>> on SNP).
>>>
>> Yes, parsing the full report will always be an option. But reading
>> static MRs like MRCONDFIGID or HOSTDATA from sysfs attributes will be
>> way more convenient.
> 
> But, theoretically, you cannot really trust what your read from the kernel for
> such *single field*, because to truly get verified you will need to get the full
> report anyway.
> 
Not exactly. Whatever the kernel extracts from a report deemed 
trustworthy by the kernel itself is implicitly trusted by any 
application having the kernel in its TCB. And in fact, every application 
has the kernel in its TCB. Therefore, MRCONFIGID or HOSTDATA read from 
sysfs can be trusted/used directly by any applications.

>>
>> Additionally, this sysfs interface is more friendly to newcomers, as
>> everyone can tell what MRs are available from the directory tree
>> structure, rather than studying processor manuals.
>>
>>> The question here is whether there's any real benefit for the kernel to
>>> expose the provider specific report details through sysfs or could we focus on
>>> the RTMR extend capability only.
>>>
>> Again, parsing the full report is always an alternative for reading any
>> MRs from the underlying arch. But it's much more convenient to read them
>> from files, which I believe is a REAL benefit.
>>
>> Or can we flip the question around and ask: is there any real benefit
>> NOT to allow reading MRs as files and force users and applications to go
>> through an arch specific IOCTL interface?
>>
> 
> As above, I am not convinced that *reading* MRs alone is that useful.  What you
> need is a unified way to *extend* those MRs.
> 
See my response above.

> And yeah I agree extending arch-specific IOCTL to support extending any runtime
> MR isn't a good idea.
>

On 2/13/25 13:50, Xing, Cedric wrote:
> On 2/13/2025 10:58 AM, Dave Hansen wrote:
...
>> Wait a sec, so there's already ABI for manipulating these? This just
>> adds a parallel sysfs interface to the existing ABI?
>>
> No, this is new. There's no existing ABI for accessing measurement
> registers from within a TVM (TEE VM). Currently, on TDX for example,
> reading TDX measurement registers (MRs) must be done by getting a TD
> quote. And there's no way to extend any RTMRs. Therefore, it would be
> much easier end users to debug/diagnose measurement related issues
> (which would almost always require reading MRs) with this patch.

Ok, that makes sense.

But if this is for debug, wouldn't these belong better in debugfs? Do we
really want to maintain this interface forever? There's no shame in debugfs.

>> Also, you're saying that users don't need to write any code, but then
>> provide... sample code. That's unexpected.
>>
> The sample code is to demo how to expose MRs from a CC guest driver, but
> not for end users to access those MRs.
> 
>> Oh, and you seem to have forgotten to attach the sysfs ABI documentation
>> patch to the series. You did write the required documentation, right? ;)
> Documentation/ABI/testing/sysfs-kernel-tsm (new file added by patch 1)
> contains a description on the attributes added by the patch.

Whoops! I went looking for it but I'm blind, evidently. Thanks for
pointing it out.

On 2/13/2025 5:19 PM, Dave Hansen wrote:
> On 2/13/25 13:50, Xing, Cedric wrote:
>> On 2/13/2025 10:58 AM, Dave Hansen wrote:
> ...
>>> Wait a sec, so there's already ABI for manipulating these? This just
>>> adds a parallel sysfs interface to the existing ABI?
>>>
>> No, this is new. There's no existing ABI for accessing measurement
>> registers from within a TVM (TEE VM). Currently, on TDX for example,
>> reading TDX measurement registers (MRs) must be done by getting a TD
>> quote. And there's no way to extend any RTMRs. Therefore, it would be
>> much easier end users to debug/diagnose measurement related issues
>> (which would almost always require reading MRs) with this patch.
> 
> Ok, that makes sense.
> 
> But if this is for debug, wouldn't these belong better in debugfs? Do we
> really want to maintain this interface forever? There's no shame in debugfs.
> 
There are many other (more important/significant) uses besides debugging.

For example, any applications that make use of runtime measurements must 
extend RTMRs, and this interface provides that exact functionality.

Another example, a policy may be associated with a TD (e.g., CoCo) by 
storing its digest in MRCONFIGID, so that the policy could be verified 
against its digest at runtime. This interface allows applications to 
read MRCONFIGID.

On 2/14/25 08:19, Xing, Cedric wrote:
>> But if this is for debug, wouldn't these belong better in debugfs? Do we
>> really want to maintain this interface forever? There's no shame in
>> debugfs.
>>
> There are many other (more important/significant) uses besides debugging.
> 
> For example, any applications that make use of runtime measurements must
> extend RTMRs, and this interface provides that exact functionality.
> 
> Another example, a policy may be associated with a TD (e.g., CoCo) by
> storing its digest in MRCONFIGID, so that the policy could be verified
> against its digest at runtime. This interface allows applications to
> read MRCONFIGID.

The attestation world is horrifically complicated, and I don't
understand the details at _all_. You're going to have to explain this
one to me like I'm five.

Could you also explain how this is different from the hardware and
virtual TPMs and why this doesn't fit into that existing framework? How
are TVMs novel? What justifies all this new stuff?

On 2/14/2025 10:26 AM, Dave Hansen wrote:
> On 2/14/25 08:19, Xing, Cedric wrote:
>>> But if this is for debug, wouldn't these belong better in debugfs? Do we
>>> really want to maintain this interface forever? There's no shame in
>>> debugfs.
>>>
>> There are many other (more important/significant) uses besides debugging.
>>
>> For example, any applications that make use of runtime measurements must
>> extend RTMRs, and this interface provides that exact functionality.
>>
>> Another example, a policy may be associated with a TD (e.g., CoCo) by
>> storing its digest in MRCONFIGID, so that the policy could be verified
>> against its digest at runtime. This interface allows applications to
>> read MRCONFIGID.
> 
> The attestation world is horrifically complicated, and I don't
> understand the details at _all_. You're going to have to explain this
> one to me like I'm five.
> 
> Could you also explain how this is different from the hardware and
> virtual TPMs and why this doesn't fit into that existing framework? How
> are TVMs novel? What justifies all this new stuff?
TVM (TEE VM) is a broad term referring to encrypted/protected VMs on 
various confidential computing (CC) architectures, such as AMD SEV, Arm 
CCA, Intel TDX, etc. Each of these architectures includes hardware 
components for storing software measurements, known as measurement 
registers (MRs). This patch series aims to provide the necessary 
functionality for applications that need to access these MRs.

There are no real/hardware TPMs but only virtual ones in TVMs. Virtual 
TPMs can be built upon the native MRs provided by the underlying CC 
architectures.

If you need more detailed information, I'd be happy to discuss it 
further offline to avoid cluttering the mailing list.

On 2/14/25 3:59 PM, Xing, Cedric wrote:
> On 2/14/2025 10:26 AM, Dave Hansen wrote:
>> On 2/14/25 08:19, Xing, Cedric wrote:
>>>> But if this is for debug, wouldn't these belong better in debugfs? 
>>>> Do we
>>>> really want to maintain this interface forever? There's no shame in
>>>> debugfs.
>>>>
>>> There are many other (more important/significant) uses besides 
>>> debugging.
>>>
>>> For example, any applications that make use of runtime measurements 
>>> must
>>> extend RTMRs, and this interface provides that exact functionality.
>>>
>>> Another example, a policy may be associated with a TD (e.g., CoCo) by
>>> storing its digest in MRCONFIGID, so that the policy could be verified
>>> against its digest at runtime. This interface allows applications to
>>> read MRCONFIGID.
>>
>> The attestation world is horrifically complicated, and I don't
>> understand the details at _all_. You're going to have to explain this
>> one to me like I'm five.
>>
>> Could you also explain how this is different from the hardware and
>> virtual TPMs and why this doesn't fit into that existing framework? How
>> are TVMs novel? What justifies all this new stuff?
> TVM (TEE VM) is a broad term referring to encrypted/protected VMs on 
> various confidential computing (CC) architectures, such as AMD SEV, 
> Arm CCA, Intel TDX, etc. Each of these architectures includes hardware 
> components for storing software measurements, known as measurement 
> registers (MRs). This patch series aims to provide the necessary 
> functionality for applications that need to access these MRs.
>
> There are no real/hardware TPMs but only virtual ones in TVMs. Virtual 
> TPMs can be built upon the native MRs provided by the underlying CC 
> architectures.
>
> If you need more detailed information, I'd be happy to discuss it 
> further offline to avoid cluttering the mailing list.
>
Hi Dave,

Let me try to add more plain language usages.

This ABI lets applications extend events after boot such that they can be
part of the hardware-based attestation.

One common reason is to _identify the workload_ running in the VM.
Typically a VM attestation tells you that you booted to a clean state.
It is much more valuable to a Relying Party to know that they are 
interacting
with a trusted application / workload.
Projects like CNCF Confidential Containers [1] and Attested Containers
[2] would like to do this.

More generally, Relying Parties can track the state of an application in
the attestation. Auctions are common examples of stateful flows where it
can be meaningful to, e.g., attest that a bid arrived before or after the
close of an auction.

[1] 
https://github.com/confidential-containers/guest-components/blob/main/attestation-agent/attester/src/tdx/rtmr.rs
[2] https://github.com/intel/acon

Thanks,
Dan Middleton

On 2/18/25 08:25, Dan Middleton wrote:
> One common reason is to _identify the workload_ running in the VM.
> Typically a VM attestation tells you that you booted to a clean state.
> It is much more valuable to a Relying Party to know that they are
> interacting
> with a trusted application / workload.
> Projects like CNCF Confidential Containers [1] and Attested Containers
> [2] would like to do this.

That's a _bit_ of a different story than the series author mentioned here:


https://lore.kernel.org/all/be7e3c9d-208a-4bda-b8cf-9119f3e0c4ce@intel.com/

It would be great to see a solid, consistent story about what the
purpose of this series is when v2 is posted. As always, it would be even
better if it was obvious that this is not tied to one vendor or one
architecture.

If there are actual end users who care about this, it would be great to
see their acks on it as well.

On Tue, Feb 18, 2025 at 8:57 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 2/18/25 08:25, Dan Middleton wrote:
> > One common reason is to _identify the workload_ running in the VM.
> > Typically a VM attestation tells you that you booted to a clean state.
> > It is much more valuable to a Relying Party to know that they are
> > interacting
> > with a trusted application / workload.
> > Projects like CNCF Confidential Containers [1] and Attested Containers
> > [2] would like to do this.
>
> That's a _bit_ of a different story than the series author mentioned here:
>
>
> https://lore.kernel.org/all/be7e3c9d-208a-4bda-b8cf-9119f3e0c4ce@intel.com/
>
> It would be great to see a solid, consistent story about what the
> purpose of this series is when v2 is posted. As always, it would be even
> better if it was obvious that this is not tied to one vendor or one
> architecture.
>
> If there are actual end users who care about this, it would be great to
> see their acks on it as well.
>

We would like to have this for Google Confidential Space and Kubernetes Engine.

Acked-by: Dionna Glaze <dionnaglaze@google.com>


-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)

Dionna Amalie Glaze wrote:
> On Tue, Feb 18, 2025 at 8:57 AM Dave Hansen <dave.hansen@intel.com> wrote:
> >
> > On 2/18/25 08:25, Dan Middleton wrote:
> > > One common reason is to _identify the workload_ running in the VM.
> > > Typically a VM attestation tells you that you booted to a clean state.
> > > It is much more valuable to a Relying Party to know that they are
> > > interacting
> > > with a trusted application / workload.
> > > Projects like CNCF Confidential Containers [1] and Attested Containers
> > > [2] would like to do this.
> >
> > That's a _bit_ of a different story than the series author mentioned here:
> >
> >
> > https://lore.kernel.org/all/be7e3c9d-208a-4bda-b8cf-9119f3e0c4ce@intel.com/
> >
> > It would be great to see a solid, consistent story about what the
> > purpose of this series is when v2 is posted. As always, it would be even
> > better if it was obvious that this is not tied to one vendor or one
> > architecture.
> >
> > If there are actual end users who care about this, it would be great to
> > see their acks on it as well.
> >
> 
> We would like to have this for Google Confidential Space and Kubernetes Engine.
> 
> Acked-by: Dionna Glaze <dionnaglaze@google.com>

Safe to assume I can carry this ack forward to the latest iteration [1]?
This is as I look get this into linux-next shortly.

[1]: http://lore.kernel.org/20250424-tdx-rtmr-v5-0-4fe28ddf85d4@intel.com

On 2/18/25 15:57, Dionna Amalie Glaze wrote:
>> If there are actual end users who care about this, it would be great to
>> see their acks on it as well.
>>
> We would like to have this for Google Confidential Space and Kubernetes Engine.
> 
> Acked-by: Dionna Glaze <dionnaglaze@google.com>

Great! Thanks for chiming in. Can you talk for a second, though, about
why this is useful and how you plan to use it? Is it for debugging?

On Tue, Feb 18, 2025 at 4:41 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 2/18/25 15:57, Dionna Amalie Glaze wrote:
> >> If there are actual end users who care about this, it would be great to
> >> see their acks on it as well.
> >>
> > We would like to have this for Google Confidential Space and Kubernetes Engine.
> >
> > Acked-by: Dionna Glaze <dionnaglaze@google.com>
>
> Great! Thanks for chiming in. Can you talk for a second, though, about
> why this is useful and how you plan to use it? Is it for debugging?

Confidential space on SEV depends on the hypervisor-provided vTPM to
provide remotely attestable quotes of its PCRs, and the corresponding
event logs.
https://github.com/google/go-tpm-tools/blob/main/launcher/agent/agent.go#L97

On TDX and ARM CCA (maybe RISC-V CoVE someday), we don't want to have
to depend on the vTPM.
There are runtime measurement registers and the CCEL.
When we have a sysfs interface to extend these registers, it makes the
user space evidence manager's life easier.
When Dan Williams forced the issue about configfs-tsm, we were told
that it is bad for the kernel to have many platform-specific
interfaces for attestation operations.
This patch series is a way to unify behind the tsm.

As for the ability to read the registers through sysfs instead of just
extend-on-write, that's not something Confidential Space depends on
specifically.
Our attestation policies are evaluated in a verification service
rather than on-node.

For on-node policy evaluation, for instance in kubectl, there is a
benefit to being able to generically read measurement registers that
have been extended generically to execute policy that a certain action
if a measurement register isn't an exact expected value.
This is not far-fetched, since it is used for confidential containers,
and is being discussed for kubernetes engine as a way to poison an
instance when an ssh session is terminated for a human operator.

To have that same capability without a generic read interface, we need
to stuff kubectl with quote parsers of every attestation technology.

Hope that helps.
-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)

On Tue, 2025-02-18 at 19:21 -0800, Dionna Amalie Glaze wrote:
> On Tue, Feb 18, 2025 at 4:41 PM Dave Hansen <dave.hansen@intel.com>
> wrote:
> > 
> > On 2/18/25 15:57, Dionna Amalie Glaze wrote:
> > > > If there are actual end users who care about this, it would be
> > > > great to see their acks on it as well.
> > > > 
> > > We would like to have this for Google Confidential Space and
> > > Kubernetes Engine.
> > > 
> > > Acked-by: Dionna Glaze <dionnaglaze@google.com>
> > 
> > Great! Thanks for chiming in. Can you talk for a second, though,
> > about why this is useful and how you plan to use it? Is it for
> > debugging?
> 
> Confidential space on SEV depends on the hypervisor-provided vTPM to
> provide remotely attestable quotes of its PCRs, and the corresponding
> event logs.
> https://github.com/google/go-tpm-tools/blob/main/launcher/agent/agent.go#L97
> 
> On TDX and ARM CCA (maybe RISC-V CoVE someday), we don't want to have
> to depend on the vTPM.

I still don't get why one of the goals seems to be to artificially
separate AMD Confidential Computing from Intel (and now Arm and RISC-
V).

> There are runtime measurement registers and the CCEL.
> When we have a sysfs interface to extend these registers, it makes
> the user space evidence manager's life easier.
> When Dan Williams forced the issue about configfs-tsm, we were told
> that it is bad for the kernel to have many platform-specific
> interfaces for attestation operations.
> This patch series is a way to unify behind the tsm.

You say "unify behind", but this proposal doesn't include AMD and it
could easily.  All these RTMR systems are simply subsets of a TPM
functionality with non-standard (and different between each of them)
quoting mechanisms.  The only real substantive difference between RTMR
systems and TPM2 is the lack of algorithm agility.  If everyone is
determined to repeat the mistakes of history, TPM2 can easily be
exposed with a pejorative algorithm, so it could fit into this
structure with whatever the chosen hash is and definitely should be so
the interface can really become a universal one applying to both Intel
*and* AMD.

The only real argument against adding a TPM that I've seen is that it
potentially expands the use beyond confidential VMs, which, in an
interface claiming to be universal, I think is actually a good thing. 
There are many non-CC use cases that would really like a non-repudiable
logging system.

Just on algorithm agility, could I make one more plea to add it to the
API before it's set in stone.  You might think sha384 will last
forever, but then that's what the TPM1 makers thought of sha1 and that
design decision hasn't been well supported by history.  The proposal is
here:

https://lore.kernel.org/linux-coco/86e6659bc8dd135491dc34bdb247caf05d8d2ad8.camel@HansenPartnership.com/

Worst case is I'm wrong and you're right and we have an additional
directory in the configfs tree (and you never get to see my tiktok I
told you so dance).  But if I'm right, we've got algorithm agility
(especially if post-quantum has some impact on hashes that hasn't been
foreseen) built in from the get go instead of having to be welded on
after the fact when we run into problems.

All I need at this stage is crypto agility in the configfs ABI.  I can
add vTPM code to that without anyone at Intel having to worry about it.

Regards,

James

On 2/19/25 7:29 AM, James Bottomley wrote:
> On Tue, 2025-02-18 at 19:21 -0800, Dionna Amalie Glaze wrote:
>> On Tue, Feb 18, 2025 at 4:41 PM Dave Hansen <dave.hansen@intel.com>
>> wrote:
>>>
>>> On 2/18/25 15:57, Dionna Amalie Glaze wrote:
>>>>> If there are actual end users who care about this, it would be
>>>>> great to see their acks on it as well.
>>>>>
>>>> We would like to have this for Google Confidential Space and
>>>> Kubernetes Engine.
>>>>
>>>> Acked-by: Dionna Glaze <dionnaglaze@google.com>
>>>
>>> Great! Thanks for chiming in. Can you talk for a second, though,
>>> about why this is useful and how you plan to use it? Is it for
>>> debugging?
>>
>> Confidential space on SEV depends on the hypervisor-provided vTPM to
>> provide remotely attestable quotes of its PCRs, and the corresponding
>> event logs.
>> https://github.com/google/go-tpm-tools/blob/main/launcher/agent/agent.go#L97
>>
>> On TDX and ARM CCA (maybe RISC-V CoVE someday), we don't want to have
>> to depend on the vTPM.
> 
> I still don't get why one of the goals seems to be to artificially
> separate AMD Confidential Computing from Intel (and now Arm and RISC-
> V).
> 
>> There are runtime measurement registers and the CCEL.
>> When we have a sysfs interface to extend these registers, it makes
>> the user space evidence manager's life easier.
>> When Dan Williams forced the issue about configfs-tsm, we were told
>> that it is bad for the kernel to have many platform-specific
>> interfaces for attestation operations.
>> This patch series is a way to unify behind the tsm.
> 
> You say "unify behind", but this proposal doesn't include AMD and it
> could easily.  All these RTMR systems are simply subsets of a TPM
> functionality with non-standard (and different between each of them)
> quoting mechanisms.  The only real substantive difference between RTMR
> systems and TPM2 is the lack of algorithm agility.  If everyone is
> determined to repeat the mistakes of history, TPM2 can easily be
> exposed with a pejorative algorithm, so it could fit into this
> structure with whatever the chosen hash is and definitely should be so
> the interface can really become a universal one applying to both Intel
> *and* AMD.
  > The only real argument against adding a TPM that I've seen is that it
> potentially expands the use beyond confidential VMs, which, in an
> interface claiming to be universal, I think is actually a good thing.
> There are many non-CC use cases that would really like a non-repudiable
> logging system.

Hi James,
This isn't excluding AMD. AMD just happens not to have a feature common 
to the other architectures.
Intel TDX, Arm CCA, and RISC-V COVE all provide architectural 
measurement registers. SEV happens not to have these today but should 
they in the future, they can draft off of the work here.
Might also be worth remembering the original author of the series 
represented RISC-V COVE.

While someone can emulate a TPM using the architectural measurement 
registers as a backing store, they don't have to. Certainly it's also 
possible to provide a vTPM in a protected region of memory, but that 
shouldn't block the legitimate interests of using the architectural 
features of TDX, CCA, and COVE.

> Just on algorithm agility, could I make one more plea to add it to the
> API before it's set in stone.  You might think sha384 will last
> forever, but then that's what the TPM1 makers thought of sha1 and that
> design decision hasn't been well supported by history.  The proposal is
> here:
> 
> https://lore.kernel.org/linux-coco/86e6659bc8dd135491dc34bdb247caf05d8d2ad8.camel@HansenPartnership.com/

This was helpful feedback. Cedric incorporated it into v3 of the RFC series:

https://lore.kernel.org/linux-coco/20241210-tsm-rtmr-v3-2-5997d4dbda73@intel.com/

We thought your silence on v3 meant you were happy with that feature. 
Lots of threads to track though so also not surprised if you didn't see 
it, or possible we misinterpreted your feedback.

It is retained in this patch set:
https://lore.kernel.org/linux-coco/20250212-tdx-rtmr-v1-2-9795dc49e132@intel.com/


> Worst case is I'm wrong and you're right and we have an additional
> directory in the configfs tree (and you never get to see my tiktok I
> told you so dance).  

Now I have something to look forward to today. :-D

> But if I'm right, we've got algorithm agility
> (especially if post-quantum has some impact on hashes that hasn't been
> foreseen) built in from the get go instead of having to be welded on
> after the fact when we run into problems.
> 
> All I need at this stage is crypto agility in the configfs ABI.  I can
> add vTPM code to that without anyone at Intel having to worry about it.
> 
> Regards,
> 
> James
> 

Thanks,
Dan Middleton

On Wed, 2025-02-19 at 09:24 -0600, Dan Middleton wrote:
> 
> 
> On 2/19/25 7:29 AM, James Bottomley wrote:
> > On Tue, 2025-02-18 at 19:21 -0800, Dionna Amalie Glaze wrote:
> > > On Tue, Feb 18, 2025 at 4:41 PM Dave Hansen
> > > <dave.hansen@intel.com>
> > > wrote:
> > > > 
> > > > On 2/18/25 15:57, Dionna Amalie Glaze wrote:
> > > > > > If there are actual end users who care about this, it would
> > > > > > be great to see their acks on it as well.
> > > > > > 
> > > > > We would like to have this for Google Confidential Space and
> > > > > Kubernetes Engine.
> > > > > 
> > > > > Acked-by: Dionna Glaze <dionnaglaze@google.com>
> > > > 
> > > > Great! Thanks for chiming in. Can you talk for a second,
> > > > though, about why this is useful and how you plan to use it? Is
> > > > it for debugging?
> > > 
> > > Confidential space on SEV depends on the hypervisor-provided vTPM
> > > to provide remotely attestable quotes of its PCRs, and the
> > > corresponding event logs.
> > > https://github.com/google/go-tpm-tools/blob/main/launcher/agent/agent.go#L97
> > > 
> > > On TDX and ARM CCA (maybe RISC-V CoVE someday), we don't want to
> > > have to depend on the vTPM.
> > 
> > I still don't get why one of the goals seems to be to artificially
> > separate AMD Confidential Computing from Intel (and now Arm and
> > RISC-V).
> > 
> > > There are runtime measurement registers and the CCEL.
> > > When we have a sysfs interface to extend these registers, it
> > > makes the user space evidence manager's life easier.
> > > When Dan Williams forced the issue about configfs-tsm, we were
> > > told that it is bad for the kernel to have many platform-specific
> > > interfaces for attestation operations.
> > > This patch series is a way to unify behind the tsm.
> > 
> > You say "unify behind", but this proposal doesn't include AMD and
> > it could easily.  All these RTMR systems are simply subsets of a
> > TPM functionality with non-standard (and different between each of
> > them) quoting mechanisms.  The only real substantive difference
> > between RTMR systems and TPM2 is the lack of algorithm agility.  If
> > everyone is determined to repeat the mistakes of history, TPM2 can
> > easily be exposed with a pejorative algorithm, so it could fit into
> > this structure with whatever the chosen hash is and definitely
> > should be so the interface can really become a universal one
> > applying to both Intel *and* AMD.   The only real argument against
> > adding a TPM that I've seen is that it potentially expands the use
> > beyond confidential VMs, which, in an interface claiming to be
> > universal, I think is actually a good thing. There are many non-CC
> > use cases that would really like a non-repudiable logging system.
> 
> Hi James,
> This isn't excluding AMD. AMD just happens not to have a feature
> common  to the other architectures.
> Intel TDX, Arm CCA, and RISC-V COVE all provide architectural 
> measurement registers.

Calling them "architectural" (implying via hardware) doesn't really
deflect from the fact that for everyone some pieces are going to be
software (or in this case SVSM) provided ... it shouldn't matter where
they're located.

>  SEV happens not to have these today

As I said, the vTPM is fully equivalent to a RTMR system, it's just
implemented in software.

>  but should they in the future, they can draft off of the work here.
> Might also be worth remembering the original author of the series 
> represented RISC-V COVE.
> 
> While someone can emulate a TPM using the architectural measurement 
> registers as a backing store, they don't have to. Certainly it's also
> possible to provide a vTPM in a protected region of memory, but that 
> shouldn't block the legitimate interests of using the architectural 
> features of TDX, CCA, and COVE.

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?

> > Just on algorithm agility, could I make one more plea to add it to
> > the API before it's set in stone.  You might think sha384 will last
> > forever, but then that's what the TPM1 makers thought of sha1 and
> > that design decision hasn't been well supported by history.  The
> > proposal is here:
> > 
> > https://lore.kernel.org/linux-coco/86e6659bc8dd135491dc34bdb247caf05d8d2ad8.camel@HansenPartnership.com/
> 
> This was helpful feedback. Cedric incorporated it into v3 of the RFC
> series:
> 
> https://lore.kernel.org/linux-coco/20241210-tsm-rtmr-v3-2-5997d4dbda73@intel.com/
> 
> We thought your silence on v3 meant you were happy with that feature.
> Lots of threads to track though so also not surprised if you didn't
> see it, or possible we misinterpreted your feedback.
> 
> It is retained in this patch set:
> https://lore.kernel.org/linux-coco/20250212-tdx-rtmr-v1-2-9795dc49e132@intel.com/

Heh, OK, you got me there.  After the negative reaction to the above
proposal and nothing changing in v2 I did stop reading the patch sets
...

Regards,

James

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.

Hi James,

On 2/19/2025 2:53 PM, James Bottomley wrote:
> On Wed, 2025-02-19 at 09:24 -0600, Dan Middleton wrote:
>>
>>
>> On 2/19/25 7:29 AM, James Bottomley wrote:
>>> On Tue, 2025-02-18 at 19:21 -0800, Dionna Amalie Glaze wrote:
>>>> On Tue, Feb 18, 2025 at 4:41 PM Dave Hansen
>>>> <dave.hansen@intel.com>
>>>> wrote:
>>>>>
>>>>> On 2/18/25 15:57, Dionna Amalie Glaze wrote:
>>>>>>> If there are actual end users who care about this, it would
>>>>>>> be great to see their acks on it as well.
>>>>>>>
>>>>>> We would like to have this for Google Confidential Space and
>>>>>> Kubernetes Engine.
>>>>>>
>>>>>> Acked-by: Dionna Glaze <dionnaglaze@google.com>
>>>>>
>>>>> Great! Thanks for chiming in. Can you talk for a second,
>>>>> though, about why this is useful and how you plan to use it? Is
>>>>> it for debugging?
>>>>
>>>> Confidential space on SEV depends on the hypervisor-provided vTPM
>>>> to provide remotely attestable quotes of its PCRs, and the
>>>> corresponding event logs.
>>>> https://github.com/google/go-tpm-tools/blob/main/launcher/agent/agent.go#L97
>>>>
>>>> On TDX and ARM CCA (maybe RISC-V CoVE someday), we don't want to
>>>> have to depend on the vTPM.
>>>
>>> I still don't get why one of the goals seems to be to artificially
>>> separate AMD Confidential Computing from Intel (and now Arm and
>>> RISC-V).
>>>
>>>> There are runtime measurement registers and the CCEL.
>>>> When we have a sysfs interface to extend these registers, it
>>>> makes the user space evidence manager's life easier.
>>>> When Dan Williams forced the issue about configfs-tsm, we were
>>>> told that it is bad for the kernel to have many platform-specific
>>>> interfaces for attestation operations.
>>>> This patch series is a way to unify behind the tsm.
>>>
>>> You say "unify behind", but this proposal doesn't include AMD and
>>> it could easily.  All these RTMR systems are simply subsets of a
>>> TPM functionality with non-standard (and different between each of
>>> them) quoting mechanisms.  The only real substantive difference
>>> between RTMR systems and TPM2 is the lack of algorithm agility.  If
>>> everyone is determined to repeat the mistakes of history, TPM2 can
>>> easily be exposed with a pejorative algorithm, so it could fit into
>>> this structure with whatever the chosen hash is and definitely
>>> should be so the interface can really become a universal one
>>> applying to both Intel *and* AMD.   The only real argument against
>>> adding a TPM that I've seen is that it potentially expands the use
>>> beyond confidential VMs, which, in an interface claiming to be
>>> universal, I think is actually a good thing. There are many non-CC
>>> use cases that would really like a non-repudiable logging system.
>>
This series does support crypto algo agility per your comments to the 
RFC version this same series. The 2nd patch contains a sample showing 
how to add multiple algorithms (banks) to the same MR.

It isn't limited to CC either. Any kernel module can expose arbitrary 
MRs, real or virtual, through this interface. Again, the sample code in 
the 2nd patch shows how to, and it's quite straight forward.

>> Hi James,
>> This isn't excluding AMD. AMD just happens not to have a feature
>> common  to the other architectures.
>> Intel TDX, Arm CCA, and RISC-V COVE all provide architectural
>> measurement registers.
> 
> Calling them "architectural" (implying via hardware) doesn't really
> deflect from the fact that for everyone some pieces are going to be
> software (or in this case SVSM) provided ... it shouldn't matter where
> they're located.
> 
As said above, nothing will prevent a vTPM (based on SVSM or anything 
else) driver from exposing any PCRs through the interface defined by 
this series.

>>   SEV happens not to have these today
> 
> As I said, the vTPM is fully equivalent to a RTMR system, it's just
> implemented in software.
> 
Agreed. Again, nothing will prevent a vTPM driver from exposing PCRs 
through this interface.

>>   but should they in the future, they can draft off of the work here.
>> Might also be worth remembering the original author of the series
>> represented RISC-V COVE.
>>
>> While someone can emulate a TPM using the architectural measurement
>> registers as a backing store, they don't have to. Certainly it's also
>> possible to provide a vTPM in a protected region of memory, but that
>> shouldn't block the legitimate interests of using the architectural
>> features of TDX, CCA, and COVE.
> 
> 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?
> 
To be precise, RTMRs serve the purpose of RTM (Root of Trust for 
Measurement). The TPM PCRs serve the same purpose. But neither is a 
complete RTM. Per TPM spec, RTM also includes the BIOS boot block (CRTM) 
because the TPM device doesn't have access to processor memory or the 
flash device where BIOS resides. In the case of TVMs, there are static 
MRs that capture the measurements of the initial memory image, which is 
equivalent to the CRTM but measured.

This series models the full RTM (static + runtime MRs), which isn't 
fully covered by the existing TPM framework. But again, nothing will 
prevent the driver of a TPM, real or virtual, from exposing PCRs through 
this series.

>>> Just on algorithm agility, could I make one more plea to add it to
>>> the API before it's set in stone.  You might think sha384 will last
>>> forever, but then that's what the TPM1 makers thought of sha1 and
>>> that design decision hasn't been well supported by history.  The
>>> proposal is here:
>>>
>>> https://lore.kernel.org/linux-coco/86e6659bc8dd135491dc34bdb247caf05d8d2ad8.camel@HansenPartnership.com/
>>
>> This was helpful feedback. Cedric incorporated it into v3 of the RFC
>> series:
>>
>> https://lore.kernel.org/linux-coco/20241210-tsm-rtmr-v3-2-5997d4dbda73@intel.com/
>>
>> We thought your silence on v3 meant you were happy with that feature.
>> Lots of threads to track though so also not surprised if you didn't
>> see it, or possible we misinterpreted your feedback.
>>
>> It is retained in this patch set:
>> https://lore.kernel.org/linux-coco/20250212-tdx-rtmr-v1-2-9795dc49e132@intel.com/
> 
> Heh, OK, you got me there.  After the negative reaction to the above
> proposal and nothing changing in v2 I did stop reading the patch sets
> ...
> 
Glad that you see it now!

-Cedric