linux-kernel - Re: [RFC PATCH 05/20] x86/virt/tdx: Export tdx module attributes via sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3a1bf1a72473637964a443676e59868fbfbb1ed4.camel@intel.com>
Date: Wed, 11 Jun 2025 02:09:35 +0000
From: "Huang, Kai" <kai.huang@...el.com>
To: "Gao, Chao" <chao.gao@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-coco@...ts.linux.dev"
	<linux-coco@...ts.linux.dev>, "Dong, Eddie" <eddie.dong@...el.com>,
	"Shutemov, Kirill" <kirill.shutemov@...el.com>, "Hansen, Dave"
	<dave.hansen@...el.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "Reshetova, Elena"
	<elena.reshetova@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "tglx@...utronix.de" <tglx@...utronix.de>, "Yamahata,
 Isaku" <isaku.yamahata@...el.com>, "kirill.shutemov@...ux.intel.com"
	<kirill.shutemov@...ux.intel.com>, "hpa@...or.com" <hpa@...or.com>, "Chen,
 Farrah" <farrah.chen@...el.com>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, "bp@...en8.de" <bp@...en8.de>, "x86@...nel.org"
	<x86@...nel.org>, "Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: [RFC PATCH 05/20] x86/virt/tdx: Export tdx module attributes via
 sysfs

On Tue, 2025-06-10 at 09:37 +0800, Chao Gao wrote:
> On Tue, Jun 03, 2025 at 07:49:17AM +0800, Huang, Kai wrote:
> > 
> > > 
> > > Note changes to tdx_global_metadata.{hc} are auto-generated by following
> > > the instructions detailed in [1], after modifying "version" to "versions"
> > > in the TDX_STRUCT of tdx.py to accurately reflect that it is a collection
> > > of versions.
> > > 
> > 
> > [...]
> > 
> > > +static ssize_t version_show(struct device *dev, struct device_attribute *attr,
> > > +			    char *buf)
> > > +{
> > > +	const struct tdx_sys_info_versions *v = &tdx_sysinfo.versions;
> > > +
> > > +	return sysfs_emit(buf, "%u.%u.%u\n", v->major_version,
> > > +					     v->minor_version,
> > > +					     v->update_version);
> > > +}
> > > +
> > > +static DEVICE_ATTR_RO(version);
> > > +
> > 
> > Then for this attribute, I think it is better to name it 'versions' as well?
> 
> Using 'versions' for sysfs might be confusing, as it could imply multiple TDX
> modules. It makes more sense to me that each module has __a version__ in the
> x.y.z format.
> 
> And the convention for sysfs file names is to use 'version'. E.g.,
> 
> # find . -type f -exec grep 'version_show' {} + |wc -l
> 185
> # find . -type f -exec grep 'versions_show' {} + |wc -l
> 0
> 
> Concatenating major_version/minor_version is kinda common inside the kernel,
> but 'versions' is not typically used as a sysfs name.

Sure.

But then should we just use 'version' in the names of the structure and the
variable generated via the script?

It doesn't make a lot sense to me to have this inconsistency.