Re: [RFC PATCH v1 08/11] PCI/TSM: Bind CTLV attestation to connected and locked contexts

[Jason Gunthorpe <jgg@nvidia.com>]

On Thu, Oct 29, 2026 at 11:00:03AM +0530, Aneesh Kumar K.V wrote:
> Dave Jiang <dave.jiang@intel.com> writes:
> 
> > On 10/28/26 8:26 AM, Aneesh Kumar K.V (Arm) wrote:
> >
> 
>  [ ... 232 lines skipped ... ] 
> 
> >> +	ops = tsm->tsm_dev->pci_ops;
> >> +	if (!ops->refresh_evidence)
> >> +		return -EOPNOTSUPP;
> >> +
> >> +	ret = ops->refresh_evidence(tsm, type, 0, (void *)challenge, length);
> >> +	/* Even a failed refresh may have changed device state. Retire all verdicts. */
> >> +	if (ret)
> >> +		tsm->error = true;
> >
> > Does this make any refresh failure fatal until unlock? The CCA refresh
> > in 11/11 says "failure preserve the old cache", but with tsm->error
> > set I don't think the cache can be read or accepted?
> 
> Yes. The generic layer treats an evidence refresh failure as fatal. The
> backend can decide how to present that failure.

The locked generation scheme should fully protect against any desync
issues though? Do we need to care here?

I also continue to dislike the use of the word 'cached' here, why is
this like this? If someone wants evidence they should get the fresh
evidence with their nonce returned. I can understand hanging on to
certificates and other unsigned data but then what would even trigger
a refresh of that? Something you can't refresh isn't a cache, it is
just the immutable data.

Needs some more explanation I suppose, or maybe I haven't found the
explanation yet.

> > The cached evidence is still the lock's evidence, collected after the
> > lock. And per the cover letter a failed refresh already invalidates
> > the earlier generations. Should the backend decide instead, and set
> > tsm->error itself when it can't tell what happened to the device?
> 
> For the CCA backend, evidence is replaced only after successful
> validation. If validation fails, the cached evidence remains unchanged.
> However, we could instead discard the existing evidence cache when a
> refresh starts.

What validation?

> > Also, this builds on struct pci_tsm_evidence from Dan's March posting
> > [1]. The TDX guest RFC [2] and AMD's SEV-TIO guest RFC [3] both use
> > device_evidence_create() from his July posting [4]. Is the plan to go
> > with pci_tsm_evidence and drop device_evidence? Would help to know
> > which one to build the TDX guest side on.
> >
> > [1] https://lore.kernel.org/all/20260303000207.1836586-1-dan.j.williams@intel.com/
> > [2] https://lore.kernel.org/all/20260924041032.1096569-1-zhenzhong.duan@intel.com/
> > [3] https://lore.kernel.org/all/20260916115159.1938195-16-aik@amd.com/
> > [4] https://lore.kernel.org/all/20260705220819.2472765-1-djbw@kernel.org/
> >
> 
> The include/linux/attestation.h do cover
> 
> enum attestation_device_trust_state {
> 	ATTESTATION_DEVICE_TRUST_UNSET =
> 		CTLV_ATTESTATION_DEVICE_TRUST_STATE_UNSET,
> 	ATTESTATION_DEVICE_TRUST_NONE =
> 		CTLV_ATTESTATION_DEVICE_TRUST_STATE_NONE,
> 	ATTESTATION_DEVICE_TRUST_ADVERSARY =
> 		CTLV_ATTESTATION_DEVICE_TRUST_STATE_ADVERSARY,
> 	ATTESTATION_DEVICE_TRUST_AUTO =
> 		CTLV_ATTESTATION_DEVICE_TRUST_STATE_AUTO,
> 	ATTESTATION_DEVICE_TRUST_TCB = CTLV_ATTESTATION_DEVICE_TRUST_STATE_TCB,
> };
> 
> I am still unclear how this will interact with generic device trust. We
> can only determine that after reviewing the device trust series.

I don't know why attestation subsystem would have an opinion or
interfaces for device trust?

Jason