On 2/19/25 7:29 AM, James Bottomley wrote:

On Tue, 2025-02-18 at 19:21 -0800, Dionna Amalie Glaze wrote:

quoted

On Tue, Feb 18, 2025 at 4:41 PM Dave Hansen [off-list ref]
wrote:

quoted

On 2/18/25 15:57, Dionna Amalie Glaze wrote:

quoted

quoted

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 <redacted>

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).

quoted

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/ (local)

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/ (local)

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/ (local)

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