From: Dan Williams <dan.j.williams@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>,
Dan Williams <dan.j.williams@intel.com>
Cc: <linux-coco@lists.linux.dev>, <linux-pci@vger.kernel.org>
Subject: Re: [RFC PATCH 4/5] sysfs: Introduce a mechanism to hide static attribute_groups
Date: Tue, 30 Jan 2024 08:48:26 -0800 [thread overview]
Message-ID: <65b9285a93e42_5cc6f294ac@dwillia2-mobl3.amr.corp.intel.com.notmuch> (raw)
In-Reply-To: <2024013016-sank-idly-dd6b@gregkh>
Greg KH wrote:
> On Tue, Jan 30, 2024 at 01:24:08AM -0800, Dan Williams wrote:
> > Add a mechanism for named attribute_groups to hide their directory at
> > sysfs_update_group() time, or otherwise skip emitting the group
> > directory when the group is first registered. It piggybacks on
> > is_visible() in a similar manner as SYSFS_PREALLOC, i.e. special flags
> > in the upper bits of the returned mode. To use it, specify a symbol
> > prefix to DEFINE_SYSFS_GROUP_VISIBLE(), and then pass that same prefix
> > to SYSFS_GROUP_VISIBLE() when assigning the @is_visible() callback:
> >
> > DEFINE_SYSFS_GROUP_VISIBLE($prefix)
> >
> > struct attribute_group $prefix_group = {
> > .name = $name,
> > .is_visible = SYSFS_GROUP_VISIBLE($prefix),
> > };
> >
> > SYSFS_GROUP_VISIBLE() expects a definition of $prefix_group_visible()
> > and $prefix_attr_visible(), where $prefix_group_visible() just returns
> > true / false and $prefix_attr_visible() behaves as normal.
> >
> > The motivation for this capability is to centralize PCI device
> > authentication in the PCI core with a named sysfs group while keeping
> > that group hidden for devices and platforms that do not meet the
> > requirements. In a PCI topology, most devices will not support
> > authentication, a small subset will support just PCI CMA (Component
> > Measurement and Authentication), a smaller subset will support PCI CMA +
> > PCIe IDE (Link Integrity and Encryption), and only next generation
> > server hosts will start to include a platform TSM (TEE Security
> > Manager).
> >
> > Without this capability the alternatives are:
> >
> > * Check if all attributes are invisible and if so, hide the directory.
> > Beyond trouble getting this to work [1], this is an ABI change for
> > scenarios if userspace happens to depend on group visibility absent any
> > attributes. I.e. this new capability avoids regression since it does
> > not retroactively apply to existing cases.
> >
> > * Publish an empty /sys/bus/pci/devices/$pdev/tsm/ directory for all PCI
> > devices (i.e. for the case when TSM platform support is present, but
> > device support is absent). Unfortunate that this will be a vestigial
> > empty directory in the vast majority of cases.
> >
> > * Reintroduce usage of runtime calls to sysfs_{create,remove}_group()
> > in the PCI core. Bjorn has already indicated that he does not want to
> > see any growth of pci_sysfs_init() [2].
> >
> > * Drop the named group and simulate a directory by prefixing all
> > TSM-related attributes with "tsm_". Unfortunate to not use the naming
> > capability of a sysfs group as intended.
> >
> > In comparison, there is a small potential for regression if for some
> > reason an @is_visible() callback had dependencies on how many times it
> > was called. Additionally, it is no longer an error to update a group
> > that does not have its directory already present, and it is no longer a
> > WARN() to remove a group that was never visible.
> >
> > Link: https://lore.kernel.org/all/2024012321-envious-procedure-4a58@gregkh/ [1]
> > Link: https://lore.kernel.org/linux-pci/20231019200110.GA1410324@bhelgaas/ [2]
> > Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> > ---
> > fs/sysfs/group.c | 45 ++++++++++++++++++++++++++++-------
> > include/linux/sysfs.h | 63 ++++++++++++++++++++++++++++++++++++++++---------
> > 2 files changed, 87 insertions(+), 21 deletions(-)
>
> You beat me to this again :)
Pardon the spam, was just showing it in context of the patchset I was
developing.
> I have tested this patch, and it looks good, I'll send out my series
> that uses it for a different subsystem as well.
>
> I guess I can take this as a static tag for others to pull from for this
> rc development cycle?
That works for me. Thanks Greg!
next prev parent reply other threads:[~2024-01-30 16:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 9:23 [RFC PATCH 0/5] Towards a shared TSM sysfs-ABI for Confidential Computing Dan Williams
2024-01-30 9:23 ` [RFC PATCH 1/5] PCI/CMA: Prepare to interoperate with TSM authentication Dan Williams
2024-02-08 22:09 ` Bjorn Helgaas
2024-01-30 9:23 ` [RFC PATCH 2/5] coco/tsm: Establish a new coco/tsm subdirectory Dan Williams
2024-02-09 2:24 ` Kuppuswamy Sathyanarayanan
2024-02-27 1:39 ` Dan Williams
2024-01-30 9:24 ` [RFC PATCH 3/5] coco/tsm: Introduce a shared class device for TSMs Dan Williams
2024-02-16 11:29 ` Alexey Kardashevskiy
2024-02-27 1:47 ` Dan Williams
2024-03-07 16:41 ` Jonathan Cameron
2024-03-07 19:33 ` Dan Williams
2024-01-30 9:24 ` [RFC PATCH 4/5] sysfs: Introduce a mechanism to hide static attribute_groups Dan Williams
2024-01-30 16:44 ` Greg KH
2024-01-30 16:48 ` Dan Williams [this message]
2024-01-30 17:31 ` Greg KH
2024-02-19 8:57 ` Greg KH
2024-02-22 13:22 ` Greg KH
2024-01-30 9:24 ` [RFC PATCH 5/5] PCI/TSM: Authenticate devices via platform TSM Dan Williams
2024-02-08 22:13 ` Bjorn Helgaas
2024-02-09 5:51 ` Dan Williams
2024-02-16 11:29 ` Alexey Kardashevskiy
2024-02-27 5:52 ` Dan Williams
2024-02-16 21:38 ` Alexey Kardashevskiy
2024-02-27 5:59 ` Dan Williams
2024-02-26 11:37 ` Zhi Wang
2024-02-27 6:34 ` Dan Williams
2024-02-27 19:53 ` Zhi Wang
2024-03-01 0:32 ` Dan Williams
2024-03-07 17:18 ` Jonathan Cameron
2024-03-07 19:51 ` Dan Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65b9285a93e42_5cc6f294ac@dwillia2-mobl3.amr.corp.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.