Message-ID: <d5db93c2-9ce4-4ad7-a64c-cbf3c1020ff5@intel.com>
Date: Wed, 19 Feb 2025 16:25:24 -0600
From: "Xing, Cedric" <cedric.xing@...el.com>
To: James Bottomley <James.Bottomley@...senPartnership.com>, Dan Middleton
	<dan.middleton@...ux.intel.com>, Dionna Amalie Glaze
	<dionnaglaze@...gle.com>, Dave Hansen <dave.hansen@...el.com>
CC: Dan Williams <dan.j.williams@...el.com>, "Kirill A. Shutemov"
	<kirill.shutemov@...ux.intel.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
	Borislav Petkov <bp@...en8.de>, <x86@...nel.org>, "H. Peter Anvin"
	<hpa@...or.com>, <linux-kernel@...r.kernel.org>,
	<linux-coco@...ts.linux.dev>, Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@...ux.intel.com>
Subject: Re: [PATCH 0/4] tsm: Unified Measurement Register ABI for TVMs

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@...el.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@...gle.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

Powered by blists - more mailing lists