Re: [PATCH v2 0/3] Expose TDX Module version

[<dan.j.williams@intel.com>]

Dave Hansen wrote:
[..]
> Since there's a dearth of discussion of this topic in the changelog or
> cover letter, my working assumption is that Chao did not consider any of
> this before posting.

Unfortunately that is incorrect, harsh, but somewhat forgivable because
features like TDX module update and the PCI device security stuff
stretch the boundaries of what tip.git historically needed to worry
about.

For example, the equivalent on the SNP side goes through
drivers/crypto/ccp/ which sometimes Boris takes changes through tip.git,
but many other commits, for features like "update device firmware" and
"PCI device security", go through crypto.git and now tsm.git. Case in
point, nobody in tip.git land had cause to even glance at commits like:

    2e424c33d8e7 crypto: ccp - Add support for displaying PSP firmware versions

I do not know where your specific objection lies so I am going to start
from the beginning summarizing all the discussions had around this to
date, some off list, some on list [1]. Chao has been involved in those
from the beginning and threw a fair share of consideration logs into the
fire.

The main problem for TDX with respect to the considered features of:

- sysfs to display some module metadata
- sysfs to mediate module update
- device + driver to coordinate PCI device security 

Is that TDX does not come with a device enumeration. It has no ACPI
description, it only has CPUID. Note, that at least puts TDX in a more
comfortable position than ARM which is also struggling with the "where
do we hang a useful device abstraction for this software pseudo
hypervisor thingy that controls confidential computing".

For sake of argument, I assume you have no fundamental objection to
module version information in sysfs in general? I.e. is the question
more on the where and how for TDX sysfs?

Note that back in March of last year there was this nak from me on the
proposal for something like a custom crafted /sys/hypervisor hierarchy
[2]. I still hold the same position today that all these archs are to
have widely different ways to enumerate their capabilities.  Anything
implementation specific should hang off an implementation specific
device. Everything else that is cross-arch should create a shared class
device. We now have that "shared class device" upstream via
tsm_register() [3].

For TDX the question is what is the best path to create a device
abstraction for a technology that does not come with a PCI device nor a
firmware enumerated platform device. The faux device infrastructure was
purpose built for cases like this. Now, faux device arrived in February
after I had sent out my original "tdx_subsys" proposal in January [1].
While I found the /sys/devices/faux path prefix somewhat unsavory
compared to /sys/devices/virtual, the implementation does exactly what
is needed and avoids the abuses of /sys/devices/platform that would
usually result from cases like this.

It turns out ARM is strongly recommended to go the faux device route as
well [4], so if you have other ideas here you have some work ahead to
undo some standing consensus.

As for which patch set should introduce this new device, I am in favor
of following Chao's lead here. Land the least controversial of all
possible TDX module metadata to publish in sysfs, a version string.
This simple infrastructure unblocks the path for the module update and
PCI device security features. Those add more attributes, a fw_upload
instance, and an idiomatic driver model for the tail of TDX features
that are more suitable for driver enabling than core-x86 enabling.

Yes, you were not directly copied on any of the references I have below,
yes you are free to have an opinion on proposals you are not copied.
However, going forward I would like to negotiate some working model
similar to the tip.git relationship to drivers/crypto/ccp/, and work on
how to avoid surprises like this in the future.

[1]: Earliest on list concept of needing device infrastructure for TDX
features: http://lore.kernel.org/170660662589.224441.11503798303914595072.stgit@dwillia2-xfh.jf.intel.com
[2]: http://lore.kernel.org/67d4bee77313a_12e31294c7@dwillia2-xfh.jf.intel.com.notmuch
[3]: http://lore.kernel.org/20251031212902.2256310-2-dan.j.williams@intel.com
[4]: http://lore.kernel.org/2025073035-bulginess-rematch-b92e@gregkh