linux-kernel - Re: [RFC PATCH v1 1/3] x86/tdx: Make TDX metadata available 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] [day] [month] [year] [list]

Message-ID: <67daf7c37b2f0_201f0294a4@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 19 Mar 2025 09:58:43 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Dan Williams
	<dan.j.williams@...el.com>, Joerg Roedel <jroedel@...e.de>
CC: Alexey Gladkov <legion@...nel.org>, <x86@...nel.org>,
	<linux-kernel@...r.kernel.org>, <linux-coco@...ts.linux.dev>, Alexey Gladkov
	<alexey.gladkov@...el.com>, "H . Peter Anvin" <hpa@...or.com>, Juergen Gross
	<jgross@...e.com>, <Larry.Dewey@....com>, Nikunj A Dadhania <nikunj@....com>,
	Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [RFC PATCH v1 1/3] x86/tdx: Make TDX metadata available via SYSFS

Kirill A . Shutemov wrote:
[..]
> > > Dan, could you elaborate on what is actual proposal? I am not sure I
> > > understand what 'struct device' can have info on TDX module version be
> > > attached to it.
> > 
> > Confused, you do not understand that devices can have sysfs attributes?
> 
> I didn't understand what device it would be in TDX case.

Oh, *which* device, now I understand the disconnect.

> > Documentation/ABI/testing/sysfs-driver-ccp describes a device object and
> > sysfs attributes for SEV-SNP firmware status.
> > 
> > For TDX, the proposal is to create virtual device to stand in for the
> > lack of a PCI device that fills the same role as AMD PSP.
> 
> Okay, I got it.
> 
> Do you see a problem having the same interface for both host and guest?
> We obviously need indication what level we are running on.

While I see no problem with /sys/devices/virtual/tdx appearing in both
host and guest, that needs to be reconciled with the fact that both
SEV-SNP and TDX created misc devices in the guest.

As for conveying level, the configs-tsm (soon to be renamed
configs-tsm-report) ABI already conveys the level for SEV-SNP if you are
talking about VMPL. 

> > With the expectation that all TSM technolgies (SEV-SNP, TDX, CCA, etc)
> > register a device, udev rules can trigger off a common class device
> > uevent. That proposal is detailed here [1]:
> > 
> > [1]: http://lore.kernel.org/174107247268.1288555.9365605713564715054.stgit@dwillia2-xfh.jf.intel.com
> 
> Joerg, what do you think? How does it fit your ideas for SEV-SNP?

As I noted, both technologies currently register guest misc devices, so
natural place for some simple guest side vendor-specific sysfs
attributes would be via the @groups property of 'struct miscdevice'.
Otherwise, the proposal for cross-vendor TSM sysfs interface is via a
/sys/class/tsm device. For now I only have patches for the host side of
that for generically conveying which PCI devices are consuming link
encryption resources in the platform TSM.