Re: [RFC PATCH v1 02/11] attestation: Filter evidence objects per instance

[Jiri Pirko <jiri@resnulli.us>]

Sat, Oct 31, 2026 at 07:24:47AM +0100, aneesh.kumar@kernel.org wrote:
>Jiri Pirko <jiri@resnulli.us> writes:
>
>> Wed, Oct 28, 2026 at 04:26:09PM +0100, aneesh.kumar@kernel.org wrote:
>>>Allow an attestation instance to expose only the evidence objects its
>>>device supports. Add an optional evidence_object_supported() callback
>>>and use it both when building DEVICE_GET capabilities and when checking
>>>EVIDENCE_GET requests.
>>>
>>>The following PCI/TSM patch uses one attestation implementation for
>>>devices that support different evidence objects. Its list includes
>>>certificate slots 0-7, SPDM VCA, measurements, and a TDISP interface
>>>report. Each device must expose only the objects it supports, for
>>>example:
>>>
>>>  Instance                  Supported evidence objects
>>>  ------------------------  ------------------------------------------
>>>  Host link using slot zero Certificate slot 0
>>>  CCA guest device          Certificate slot 0, VCA, measurements,
>>>                            TDISP interface report
>>>  Host PF0 after discovery  Certificate slots reported populated by SPDM
>>>
>>>PCI/TSM checks the TSM driver's evidence_types bitmap or, after SPDM
>>>discovery on a host PF0, the populated-slot bitmap. The preceding patch
>>>controls whether EVIDENCE_GET is enabled; this patch controls which
>>>objects that operation can retrieve.
>>
>> For SPDM slots, I think it would make sense to distinguish supported
>> slot addresses from discovered population. DEVICE_GET describes fixed
>> object tuples, formats and limits; SPDM_GET reports the populated
>> slots and their certificate digests. An empty supported slot
>> returns -ENOENT.
>>
>> Fixed differences between backend instances can be selected before
>> publication. Please do not make the capability set follow a
>> populated-slot bitmap that can change during the instance lifetime.
>>
>> [..]
>
>
>We still need to filter objects such as measurements and the interface
>report based on the backend instance. Are you suggesting that we do this
>in attestation_evidence_object_find()? 
>
>supported = attestation_evidence_object_find(att, blob_class, has_instance,
>					     instance, format);
>if (!supported || !attestation_representation_in(supported, representation)) {
>	kfree(objects);
>	return -EOPNOTSUPP;
>}
>
>So the backend will have some way to indicate which objects it supports,
>such as the TSM driver's evidence_types bitmap, with the host setting it
>to indicate support for only CERT_CHAIN[0-7]?

Yes, that is what I meant. DEVICE_GET and
attestation_evidence_object_find() should apply the same per-instance
support filter. Using the TSM driver's evidence_types bitmap to select
the provider's supported-object descriptions is fine.

That handles backend differences such as support for measurements and
the interface report. For a host backend supporting all eight slot
addresses, the supported set can contain CERT_CHAIN[0-7].

My concern was only using the populated-slot bitmap for this filtering.
The supported set should be fixed before publication; current slot
population is separate state reported by SPDM_GET.

A request for an unsupported object returns -EOPNOTSUPP. A request for
a supported certificate slot that is currently empty returns -ENOENT.