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

[Jiri Pirko <jiri@resnulli.us>]

Fri, Oct 30, 2026 at 04:39:00PM +0100, jgg@nvidia.com wrote:
>On Fri, Oct 30, 2026 at 03:08:52PM +0100, Jiri Pirko wrote:
>> Wed, Oct 28, 2026 at 04:26:15PM +0100, aneesh.kumar@kernel.org wrote:
>> 
>> [..]
>> 
>> > 		available authentication methods for the device.
>> > 
>> > 		When present and the tsm/ attribute directory is present, the
>> >-		authenticated attribute is an alias for the device 'connect'
>> >-		state. See the 'tsm/connect' attribute for more details.
>> >+		authenticated attribute reports the TSM name only after secure
>> >+		session and stream setup succeed, otherwise an empty string.
>> >+		Connection control uses tsm/connect and tsm/disconnect.
>> > 		This is a "link" TSM attribute, see
>> > 		Documentation/ABI/testing/sysfs-class-tsm.
>> 
>> [..]
>> 
>> > static ssize_t authenticated_show(struct device *dev,
>> > 				  struct device_attribute *attr, char *buf)
>> > {
>> >-	/*
>> >-	 * When the SPDM session established via TSM the 'authenticated' state
>> >-	 * of the device is identical to the connect state.
>> >-	 */
>> >-	return connect_show(dev, attr, buf);
>> >+	struct pci_dev *pdev = to_pci_dev(dev);
>> >+	struct pci_tsm_pf0 *pf0;
>> >+	int rc;
>> >+
>> >+	ACQUIRE(rwsem_read_intr, lock)(&pci_tsm_rwsem);
>> >+	rc = ACQUIRE_ERR(rwsem_read_intr, &lock);
>> >+	if (rc)
>> >+		return rc;
>> >+
>> >+	if (!pdev->tsm || !pdev->tsm->dsm_dev)
>> >+		return sysfs_emit(buf, "\n");
>> >+
>> >+	pf0 = to_pci_tsm_pf0(pdev->tsm);
>> >+	if (!pf0 || !pf0->stream_connected || pf0->base_tsm.error)
>> >+		return sysfs_emit(buf, "\n");
>> >+
>> >+	return sysfs_emit(buf, "%s\n", dev_name(&pdev->tsm->tsm_dev->dev));
>> > }
>> > static DEVICE_ATTR_RO(authenticated);
>> 
>> I had in mind removing this attribute alongside the staged connect
>> change and reporting authentication state through SPDM_GET.
>> 
>> This instead retains the attribute and changes when it reports the TSM
>> name. Could we settle that together with the SPDM_GET interface rather
>> than maintaining parallel authentication-state queries?
>> 
>> Jason, what do you think?
>
>I'm not keen on any of the sysfs, I'd like to understand who is
>expected to use this.
>
>If we imagine a systemd-device-accept-d kind of flow I don't see any
>need to duplicate things in attestation subsystem in sysfs..
>
>I'm not sure 'stream connected' is even right, as in my last note we
>should not consider the thing authenticated until we actually pass
>userspace EVIDENCE_ACCEPT, even if the TSM has established a SPDM
>session.

Agreed. The question if we can legally get rid of it at this point...