From: Dan Williams <dan.j.williams@intel.com>
To: linux-coco@lists.linux.dev
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Xiaoyao Li <xiaoyao.li@intel.com>,
Samuel Ortiz <sameo@rivosinc.com>, Lukas Wunner <lukas@wunner.de>,
Wu Hao <hao.wu@intel.com>,
Isaku Yamahata <isaku.yamahata@intel.com>,
Yilun Xu <yilun.xu@intel.com>, Alexey Kardashevskiy <aik@amd.com>,
John Allen <john.allen@amd.com>,
linux-pci@vger.kernel.org, gregkh@linuxfoundation.org
Subject: [RFC PATCH 0/5] Towards a shared TSM sysfs-ABI for Confidential Computing
Date: Tue, 30 Jan 2024 01:23:46 -0800 [thread overview]
Message-ID: <170660662589.224441.11503798303914595072.stgit@dwillia2-xfh.jf.intel.com> (raw)
As you may recall the configfs-tsm proposal [1] for conveying
attestation reports, accepted into v6.7, made the case that shared
cross-vendor concepts demand shared infrastructure. Whereas configfs-tsm
only shares guest-side transport / blob-marshaling infrastructure, the
PCIe device-security interactions with a TSM are more standardized (PCIe
TDISP) and as a result present a wider opportunity for cross-vendor
shared-semantics, not just transport infrastructure.
The proposals in this set are an attempt to intercept and reconcile
details of 4 different patchsets in various stages of making their way
upstream, TDX host patches [2], TIO preview implementation [3], SPDM/CMA
support [4], and TDX Connect preview implementation (not posted). The
guiding principle for this RFC, beyond "common concepts demand shared
infrastructure", is that PCI core concepts, defined by the PCI spec,
should live in and interoperate with the PCI core (e.g. CMA <-> TSM
interaction). The result is a /sys/bus/virtual/devices/tsm0 singleton
class device proposal with a pci/ attribute directory and a
/sys/bus/pci/devices/$pdev/tsm/ attribute directory added to each PCI
capable device that in turn coordinates with
/sys/bus/pci/devices/$pdev/authenticated.
This gives TDX, and other software-module based TSMs like RISCV COVE, a
common place to host their module attributes in
/sys/bus/virtual/devices/tsm0/host, while for SEV-SNP, and other
hardware based TSMs like ARM CCA, that /sys/bus/virtual/tsm0/host is a
symlink back to /sys/bus/pci/devices/$tsm_dev. Beyond the sysfs
device-model, for TIO, COVE-IO, and TDX Connect this gives an initial
set of library calls, locking model, and operations to support the low
level implementations.
This set has only been verified to compile, it is not functional. It is
only meant to convey the scaffolding for low level implementations to
build upon. Expect it to change as low level implementations try to
adopt it.
Otherwise, this is the first step in demonstrating that we have our act
together in terms of unifying on a common-core interface language and
low-level interface verbs. I.e. "we" the device-security kernel
developer community regarding our conversation at the BoF at Plumbers
[5] where the outcome was to unify on a set of verbs and adopt the
semantics of the low level implementation that exports the least amount
of complexity to Linux while still meeting user expectations (as simple
as possible, but no simpler).
Note that this depends on a new core-sysfs capability (patch4), with
trending positive reaction from Greg [6], to hide entire sysfs-group
attribute directories when not applicable. This further lets
implementations get away from dynamic device-attribute creation, or
worse dynamic kobject creation, that makes device ABI subsystems hard to
reason about [7].
[1]: http://lore.kernel.org/r/654438f4ca604_3f6029413@dwillia2-mobl3.amr.corp.intel.com.notmuch
[2]: http://lore.kernel.org/r/20230331154432.00001373@gmail.com
[3]: https://github.com/aik/linux/tree/tio
[4]: http://lore.kernel.org/r/cover.1695921656.git.lukas@wunner.de
[5]: https://lpc.events/event/17/contributions/1635/
[6]: http://lore.kernel.org/r/2024012855-limb-monument-cd86@gregkh
[7]: http://lore.kernel.org/r/20231019200110.GA1410324@bhelgaas
---
Dan Williams (5):
PCI/CMA: Prepare to interoperate with TSM authentication
coco/tsm: Establish a new coco/tsm subdirectory
coco/tsm: Introduce a shared class device for TSMs
sysfs: Introduce a mechanism to hide static attribute_groups
PCI/TSM: Authenticate devices via platform TSM
Documentation/ABI/testing/sysfs-bus-pci | 53 ++++
Documentation/ABI/testing/sysfs-class-tsm | 35 +++
drivers/pci/Kconfig | 15 +
drivers/pci/Makefile | 2
drivers/pci/cma.c | 12 +
drivers/pci/pci-sysfs.c | 3
drivers/pci/pci.h | 14 +
drivers/pci/probe.c | 1
drivers/pci/remove.c | 1
drivers/pci/tsm.c | 346 +++++++++++++++++++++++++++++
drivers/virt/coco/Kconfig | 6 -
drivers/virt/coco/Makefile | 4
drivers/virt/coco/sev-guest/sev-guest.c | 8 -
drivers/virt/coco/tdx-guest/tdx-guest.c | 8 -
drivers/virt/coco/tsm/Kconfig | 14 +
drivers/virt/coco/tsm/Makefile | 10 +
drivers/virt/coco/tsm/class.c | 112 +++++++++
drivers/virt/coco/tsm/pci.c | 83 +++++++
drivers/virt/coco/tsm/reports.c | 24 +-
drivers/virt/coco/tsm/tsm.h | 28 ++
fs/sysfs/group.c | 45 +++-
include/linux/pci.h | 3
include/linux/sysfs.h | 63 ++++-
include/linux/tsm.h | 109 ++++++++-
include/uapi/linux/pci_regs.h | 3
25 files changed, 935 insertions(+), 67 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-tsm
create mode 100644 drivers/pci/tsm.c
create mode 100644 drivers/virt/coco/tsm/Kconfig
create mode 100644 drivers/virt/coco/tsm/Makefile
create mode 100644 drivers/virt/coco/tsm/class.c
create mode 100644 drivers/virt/coco/tsm/pci.c
rename drivers/virt/coco/{tsm.c => tsm/reports.c} (94%)
create mode 100644 drivers/virt/coco/tsm/tsm.h
The unstable baseline of this series is a merge of
https://github.com/l1k/linux/commit/f3dc1e0eb451 and v6.8-rc2.
next reply other threads:[~2024-01-30 9:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 9:23 Dan Williams [this message]
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
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=170660662589.224441.11503798303914595072.stgit@dwillia2-xfh.jf.intel.com \
--to=dan.j.williams@intel.com \
--cc=aik@amd.com \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hao.wu@intel.com \
--cc=isaku.yamahata@intel.com \
--cc=john.allen@amd.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=sameo@rivosinc.com \
--cc=thomas.lendacky@amd.com \
--cc=xiaoyao.li@intel.com \
--cc=yilun.xu@intel.com \
/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.