From: Alistair Francis <alistair.francis@wdc.com>

Security Protocols and Data Models (SPDM) [1] is used for authentication,
attestation and key exchange. SPDM is generally used over a range of
transports, such as PCIe, MCTP/SMBus/I3C, ATA, SCSI, NVMe or TCP.

From the kernels perspective SPDM is used to authenticate and attest devices.
In this threat model a device is considered untrusted until it can be verified
by the kernel and userspace using SPDM. As such SPDM data is untrusted data
that can be mallicious.

The SPDM specification is also complex, with the 1.2.1 spec being almost 200
pages and the 1.3.0 spec being almost 250 pages long.

As such we have the kernel parsing untrusted responses from a complex
specification, which sounds like a possible exploit vector. This is the type
of place where Rust excels!

This series implements a SPDM requester in Rust.

This is very similar to Lukas' implementation [2]. This series includes patches
and files from Lukas' C SPDM implementation, which isn't in mainline.

This is a standalone series and doesn't depend on Lukas' implementation.

To help with maintaining compatibility it's designed in a way to match Lukas'
design and the state struct stores the same information, although in a Rust
struct instead of the original C one.

This series exposes the data to userspace via netlink, with a single sysfs
atrribute to allow reauthentication.

All of the patches are included in the RFC, as it depends on some patches
that aren't upstream yet.

Now that Rust is no longer experimental I have picked this back up. If the
community is generally on board with a Rust implementation I can work on
sending a non-RFC version and push towards getting that merged.

The entire tree can be seen here: https://github.com/alistair23/linux/tree/alistair/spdm-rust

I'm testing the netlink data by running the following

```shell
cargo run -- --qemu-server response

qemu-system-x86_64 \
  -nic none \
  -object rng-random,filename=/dev/urandom,id=rng0 \
  -device virtio-rng-pci,rng=rng0 \
  -drive file=deploy/images/qemux86-64/core-image-pcie-qemux86-64.rootfs.ext4,if=virtio,format=raw \
  -usb -device usb-tablet -usb -device usb-kbd \
  -cpu Skylake-Client \
  -machine q35,i8042=off \
  -smp 4 -m 2G \
  -drive file=blknvme,if=none,id=mynvme,format=raw \
  -device nvme,drive=mynvme,serial=deadbeef,spdm_port=2323,spdm_trans=doe \
  -snapshot \
  -serial mon:stdio -serial null -nographic \
  -kernel deploy/images/qemux86-64/bzImage \
  -append 'root=/dev/vda rw  console=ttyS0 console=ttyS1 oprofile.timer=1 tsc=reliable no_timer_check rcupdate.rcu_expedited=1 swiotlb=0 '

spdm_utils identify &
sleep 1
echo re > /sys/devices/pci0000:00/0000:00:03.0/authenticated
while openssl x509 -noout -text; do :; done < ~/retrieved_slot_id0
```

1: https://www.dmtf.org/standards/spdm
2: https://lore.kernel.org/all/cover.1719771133.git.lukas@wunner.de/
3: https://github.com/l1k/linux/commits/spdm-future/
4: https://lore.kernel.org/rust-for-linux/20240925205244.873020-1-benno.lossin@proton.me/
5: https://lore.kernel.org/rust-for-linux/20250107035058.818539-1-alistair@alistair23.me/

v3:
 - Use netlink to send information to userspace
 - Don't autogenerate Rust helpers
v2:
 - Drop support for Rust and C implementations
 - Include patches from Lukas to reduce series deps
 - Large code cleanups based on more testing
 - Support support for authentication

Alistair Francis (18):
  rust: add bindings for hash.h
  rust: error: impl From<FromBytesWithNulError> for Kernel Error
  lib: rspdm: Initial commit of Rust SPDM
  lib: rspdm: Support SPDM get_version
  lib: rspdm: Support SPDM get_capabilities
  lib: rspdm: Support SPDM negotiate_algorithms
  lib: rspdm: Support SPDM get_digests
  lib: rspdm: Support SPDM get_certificate
  crypto: asymmetric_keys - Load certificate parsing early in boot
  KEYS: Load keyring and certificates early in boot
  PCI/CMA: Support built in X.509 certificates
  crypto: sha: Load early in boot
  crypto: ecdsa: Load early in boot
  lib: rspdm: Support SPDM certificate validation
  rust: allow extracting the buffer from a CString
  lib: rspdm: Support SPDM challenge
  PCI/CMA: Expose in sysfs whether devices are authenticated
  rust: add bindings for hash_info

Benno Lossin (1):
  rust: add untrusted data abstraction

Jonathan Cameron (1):
  PCI/CMA: Authenticate devices on enumeration

Lukas Wunner (7):
  X.509: Make certificate parser public
  X.509: Parse Subject Alternative Name in certificates
  X.509: Move certificate length retrieval into new helper
  certs: Create blacklist keyring earlier
  PCI/CMA: Validate Subject Alternative Name in certificates
  PCI/CMA: Reauthenticate devices on reset and resume
  rspdm: Multicast received signatures via netlink

 Documentation/ABI/testing/sysfs-devices-spdm |   31 +
 Documentation/netlink/specs/spdm.yaml        |  136 +++
 MAINTAINERS                                  |   14 +
 certs/blacklist.c                            |    4 +-
 certs/system_keyring.c                       |    8 +-
 crypto/asymmetric_keys/asymmetric_type.c     |    2 +-
 crypto/asymmetric_keys/x509_cert_parser.c    |    9 +
 crypto/asymmetric_keys/x509_loader.c         |   38 +-
 crypto/asymmetric_keys/x509_parser.h         |   42 +-
 crypto/asymmetric_keys/x509_public_key.c     |    2 +-
 crypto/ecdsa.c                               |    2 +-
 crypto/sha256.c                              |    2 +-
 crypto/sha3.c                                |    2 +-
 crypto/sha512.c                              |    2 +-
 drivers/pci/Kconfig                          |   16 +
 drivers/pci/Makefile                         |    4 +
 drivers/pci/cma.asn1                         |   41 +
 drivers/pci/cma.c                            |  269 +++++
 drivers/pci/doe.c                            |    5 +-
 drivers/pci/pci-driver.c                     |    1 +
 drivers/pci/pci-sysfs.c                      |    3 +
 drivers/pci/pci.c                            |   12 +-
 drivers/pci/pci.h                            |   15 +
 drivers/pci/pcie/err.c                       |    3 +
 drivers/pci/probe.c                          |    1 +
 drivers/pci/remove.c                         |    1 +
 include/keys/asymmetric-type.h               |    2 +
 include/keys/system_keyring.h                |    4 +
 include/keys/x509-parser.h                   |   57 +
 include/linux/oid_registry.h                 |    3 +
 include/linux/pci-doe.h                      |    4 +
 include/linux/pci.h                          |   16 +
 include/linux/spdm.h                         |   39 +
 include/uapi/linux/spdm_netlink.h            |   49 +
 lib/Kconfig                                  |   17 +
 lib/Makefile                                 |    2 +
 lib/rspdm/Makefile                           |   12 +
 lib/rspdm/consts.rs                          |  213 ++++
 lib/rspdm/lib.rs                             |  180 +++
 lib/rspdm/netlink-autogen.c                  |   33 +
 lib/rspdm/netlink-autogen.h                  |   22 +
 lib/rspdm/req-netlink.c                      |  197 ++++
 lib/rspdm/req-sysfs.c                        |   98 ++
 lib/rspdm/spdm.h                             |   45 +
 lib/rspdm/state.rs                           | 1093 ++++++++++++++++++
 lib/rspdm/sysfs.rs                           |   38 +
 lib/rspdm/validator.rs                       |  489 ++++++++
 rust/bindings/bindings_helper.h              |   11 +
 rust/helpers/hash.c                          |   18 +
 rust/helpers/hash_info.c                     |    8 +
 rust/helpers/helpers.c                       |    2 +
 rust/kernel/error.rs                         |   10 +
 rust/kernel/lib.rs                           |    1 +
 rust/kernel/str.rs                           |    5 +
 rust/kernel/validate.rs                      |  605 ++++++++++
 55 files changed, 3866 insertions(+), 72 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-devices-spdm
 create mode 100644 Documentation/netlink/specs/spdm.yaml
 create mode 100644 drivers/pci/cma.asn1
 create mode 100644 drivers/pci/cma.c
 create mode 100644 include/keys/x509-parser.h
 create mode 100644 include/linux/spdm.h
 create mode 100644 include/uapi/linux/spdm_netlink.h
 create mode 100644 lib/rspdm/Makefile
 create mode 100644 lib/rspdm/consts.rs
 create mode 100644 lib/rspdm/lib.rs
 create mode 100644 lib/rspdm/netlink-autogen.c
 create mode 100644 lib/rspdm/netlink-autogen.h
 create mode 100644 lib/rspdm/req-netlink.c
 create mode 100644 lib/rspdm/req-sysfs.c
 create mode 100644 lib/rspdm/spdm.h
 create mode 100644 lib/rspdm/state.rs
 create mode 100644 lib/rspdm/sysfs.rs
 create mode 100644 lib/rspdm/validator.rs
 create mode 100644 rust/helpers/hash.c
 create mode 100644 rust/helpers/hash_info.c
 create mode 100644 rust/kernel/validate.rs

-- 
2.52.0

On Wed, Feb 11, 2026 at 01:29:07PM +1000, alistair23@gmail.com wrote:
> From: Alistair Francis <alistair.francis@wdc.com>
> 
> Security Protocols and Data Models (SPDM) [1] is used for authentication,
> attestation and key exchange. SPDM is generally used over a range of
> transports, such as PCIe, MCTP/SMBus/I3C, ATA, SCSI, NVMe or TCP.
> 
> >From the kernels perspective SPDM is used to authenticate and attest devices.
> In this threat model a device is considered untrusted until it can be verified
> by the kernel and userspace using SPDM. As such SPDM data is untrusted data
> that can be mallicious.
> 
> The SPDM specification is also complex, with the 1.2.1 spec being almost 200
> pages and the 1.3.0 spec being almost 250 pages long.
> 
> As such we have the kernel parsing untrusted responses from a complex
> specification, which sounds like a possible exploit vector. This is the type
> of place where Rust excels!

I was arguing for exactly this at a recent conference, so I'm glad to
see it. It is a great meaningful usecase for rust in the kernel.

IIRC the netlink was my suggestion too, it really needs a careful
look on its own. It is much better than sysfs, but comes with its own
pitfalls.

You might want to try to break this up into two parts, one just dumps
a large text file in debugfs where there are not uAPI rules. This
would let the rust work proceed.

And another to introduce a proper uAPI for the data.

It will be easier to get the right people interested in both parts if
it is split up I think, given the size.

Jason

On Tue, 17 Feb 2026 19:56:04 -0400
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Wed, Feb 11, 2026 at 01:29:07PM +1000, alistair23@gmail.com wrote:
> > From: Alistair Francis <alistair.francis@wdc.com>
> > 
> > Security Protocols and Data Models (SPDM) [1] is used for authentication,
> > attestation and key exchange. SPDM is generally used over a range of
> > transports, such as PCIe, MCTP/SMBus/I3C, ATA, SCSI, NVMe or TCP.
> >   
> > >From the kernels perspective SPDM is used to authenticate and attest devices.  
> > In this threat model a device is considered untrusted until it can be verified
> > by the kernel and userspace using SPDM. As such SPDM data is untrusted data
> > that can be mallicious.
> > 
> > The SPDM specification is also complex, with the 1.2.1 spec being almost 200
> > pages and the 1.3.0 spec being almost 250 pages long.
> > 
> > As such we have the kernel parsing untrusted responses from a complex
> > specification, which sounds like a possible exploit vector. This is the type
> > of place where Rust excels!  
> 
> I was arguing for exactly this at a recent conference, so I'm glad to
> see it. It is a great meaningful usecase for rust in the kernel.

FWIW I'm fully on board with this as well.  More than happy to see my C
code Lukas has been carrying go away in favor of the Rust :)
It'll also finally make me learn more than a trivial level of Rust.

Jonathan

On Wed, Feb 18, 2026 at 9:56 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Wed, Feb 11, 2026 at 01:29:07PM +1000, alistair23@gmail.com wrote:
> > From: Alistair Francis <alistair.francis@wdc.com>
> >
> > Security Protocols and Data Models (SPDM) [1] is used for authentication,
> > attestation and key exchange. SPDM is generally used over a range of
> > transports, such as PCIe, MCTP/SMBus/I3C, ATA, SCSI, NVMe or TCP.
> >
> > >From the kernels perspective SPDM is used to authenticate and attest devices.
> > In this threat model a device is considered untrusted until it can be verified
> > by the kernel and userspace using SPDM. As such SPDM data is untrusted data
> > that can be mallicious.
> >
> > The SPDM specification is also complex, with the 1.2.1 spec being almost 200
> > pages and the 1.3.0 spec being almost 250 pages long.
> >
> > As such we have the kernel parsing untrusted responses from a complex
> > specification, which sounds like a possible exploit vector. This is the type
> > of place where Rust excels!
>
> I was arguing for exactly this at a recent conference, so I'm glad to
> see it. It is a great meaningful usecase for rust in the kernel.

Woo, someone is on board!

>
> IIRC the netlink was my suggestion too, it really needs a careful
> look on its own. It is much better than sysfs, but comes with its own
> pitfalls.

It was!

>
> You might want to try to break this up into two parts, one just dumps
> a large text file in debugfs where there are not uAPI rules. This
> would let the rust work proceed.

I'm currently thinking of splitting this in 3 parts. One for the
ground work patches (crypto), one for SPDM (without netlink) and then
a final one for netlink support.

I feel that this RFC proves netlink can work, which is important. For
SPDM the authenticated syfs attribute is enough to provide usefulness
to userspace to merge that while sending the netlink later.

That way hopefully everything is a little more self contained, but
still has users and value to justify being merged.

That's a good idea about debugfs though, I'll keep that in mind

Alistair

>
> And another to introduce a proper uAPI for the data.
>
> It will be easier to get the right people interested in both parts if
> it is split up I think, given the size.
>
> Jason

[ add Aneesh, Alexey, and Yilun ]

Alistair Francis wrote:
[..]
> I'm currently thinking of splitting this in 3 parts. One for the
> ground work patches (crypto), one for SPDM (without netlink) and then
> a final one for netlink support.
> 
> I feel that this RFC proves netlink can work, which is important. For
> SPDM the authenticated syfs attribute is enough to provide usefulness
> to userspace to merge that while sending the netlink later.
> 
> That way hopefully everything is a little more self contained, but
> still has users and value to justify being merged.

The split sounds good. I chatted with Lukas a bit this morning he
rightly pointed out that the crypto pre-work does not really stand on
its own without a user.

However, I notice that Aneesh needs x509 certificate parsing for his TSM
driver [1], I think TDX would benefit from the same to offload needing
to specify the wall-clock time to the module [2] for cert verification,
and SEV-TIO (already upstream) is currently missing any facility for the
host to attest the device.

[1]: http://lore.kernel.org/20250728135216.48084-17-aneesh.kumar@kernel.org
[2]: http://lore.kernel.org/20251117022311.2443900-9-yilun.xu@linux.intel.com

So one proposal to get the x509 pre-work upstream is to extend the TSM
core (drivers/pci/tsm.c) to export the certificates in sysfs, and update
the existing "authenticated" attribute to reflect the result of cert
chain validation.

This provides immediate value to the TSM "connect" flow and is smaller
than depending on the SPDM library as the first consumer. It also feels
like useful refactoring to split 'struct spdm_state' into context for a
session initiator (SPDM library) and context for the artifacts (certs +
measurements produced by either SPDM library or a TSM).

On Wed, Feb 18, 2026 at 03:40:10PM -0800, dan.j.williams@intel.com wrote:
> However, I notice that Aneesh needs x509 certificate parsing for his TSM
> driver [1], I think TDX would benefit from the same to offload needing
> to specify the wall-clock time to the module [2] for cert verification,
> and SEV-TIO (already upstream) is currently missing any facility for the
> host to attest the device.
> 
> [1]: http://lore.kernel.org/20250728135216.48084-17-aneesh.kumar@kernel.org

There's a newer version:

https://lore.kernel.org/all/20251027095602.1154418-1-aneesh.kumar@kernel.org/

This would allow upstreaming at least the three X.509 patches at the
beginning of my CMA series (and Alistair's rSPDM series) and thus
reduce the patch count a little bit.

However I don't know how far along Aneesh's CCA work is.

Note that David Howells' introduction of ML-DSA in v7.0 moves around
a lot of the X.509 code so the three X.509 patches for CMA will no longer
apply cleanly:

https://lore.kernel.org/all/2977832.1770384806@warthog.procyon.org.uk/

I'll rebase my development branch after v7.0-rc1 is out and Aneesh can
then pick up the latest version from it:

https://github.com/l1k/linux/commits/doe

Thanks,

Lukas

Lukas Wunner wrote:
> On Wed, Feb 18, 2026 at 03:40:10PM -0800, dan.j.williams@intel.com wrote:
> > However, I notice that Aneesh needs x509 certificate parsing for his TSM
> > driver [1], I think TDX would benefit from the same to offload needing
> > to specify the wall-clock time to the module [2] for cert verification,
> > and SEV-TIO (already upstream) is currently missing any facility for the
> > host to attest the device.
> > 
> > [1]: http://lore.kernel.org/20250728135216.48084-17-aneesh.kumar@kernel.org
> 
> There's a newer version:
> 
> https://lore.kernel.org/all/20251027095602.1154418-1-aneesh.kumar@kernel.org/

As I understand this still has a dependency on a new base ARM CCA
posting. So the nearest term solution is to just wire up the existing
certificate blobs retrieved by the upstream SEV-TIO driver.

> This would allow upstreaming at least the three X.509 patches at the
> beginning of my CMA series (and Alistair's rSPDM series) and thus
> reduce the patch count a little bit.

ARM CCA only needs to parse the certificates to confirm to the TSM which
public-key to use. I am struggling to find another near term need for
the kernel to parse the certificate.

> However I don't know how far along Aneesh's CCA work is.
> 
> Note that David Howells' introduction of ML-DSA in v7.0 moves around
> a lot of the X.509 code so the three X.509 patches for CMA will no longer
> apply cleanly:
> 
> https://lore.kernel.org/all/2977832.1770384806@warthog.procyon.org.uk/
> 
> I'll rebase my development branch after v7.0-rc1 is out and Aneesh can
> then pick up the latest version from it:
> 
> https://github.com/l1k/linux/commits/doe

Sounds good, but I want to focus on the blob dump interface for the
existing upstream SPDM requester, SEV-TIO, and then go from there.

On Wed, Feb 18, 2026 at 03:40:10PM -0800, dan.j.williams@intel.com wrote:

> So one proposal to get the x509 pre-work upstream is to extend the TSM
> core (drivers/pci/tsm.c) to export the certificates in sysfs, and update
> the existing "authenticated" attribute to reflect the result of cert
> chain validation.

Why do we want the validate the cert chain in the kernel? That sounds
like something the verifier should do?

And not sure we should be dumping any certs in sysfs if the plan for
the other stuff is netlink, it should be consistent I think.

Though it is a good idea to do something with the TSM too..

Jason

On Wed, Feb 18, 2026 at 08:56:14PM -0400, Jason Gunthorpe wrote:
> And not sure we should be dumping any certs in sysfs if the plan for
> the other stuff is netlink, it should be consistent I think.

It has turned out to be super convenient to expose the 8 slots with
certificate chains in sysfs for direct examination with openssl and
similar tools, without having to go through netlink.

Originally the plan was to make the certificates/slot[0..7] files
also writable and the kernel would implicitly perform a SET_CERTIFICATE
SPDM exchange with the device when writing to those files.
Unfortunately with SPDM 1.3 the spec editors made things more
complicated, *cough* sorry *more flexible* with additional CertModel
and KeyPairID attributes.  That additional complexity makes it less
suitable for sysfs, hence for *provisioning* netlink is indeed the
better choice.  But just for *reading* the certificates in the slots,
sysfs exposure is very useful.

Thanks,

Lukas

Lukas Wunner wrote:
> On Wed, Feb 18, 2026 at 08:56:14PM -0400, Jason Gunthorpe wrote:
> > And not sure we should be dumping any certs in sysfs if the plan for
> > the other stuff is netlink, it should be consistent I think.
> 
> It has turned out to be super convenient to expose the 8 slots with
> certificate chains in sysfs for direct examination with openssl and
> similar tools, without having to go through netlink.
> 
> Originally the plan was to make the certificates/slot[0..7] files
> also writable and the kernel would implicitly perform a SET_CERTIFICATE
> SPDM exchange with the device when writing to those files.
> Unfortunately with SPDM 1.3 the spec editors made things more
> complicated, *cough* sorry *more flexible* with additional CertModel
> and KeyPairID attributes.  That additional complexity makes it less
> suitable for sysfs, hence for *provisioning* netlink is indeed the
> better choice.  But just for *reading* the certificates in the slots,
> sysfs exposure is very useful.

Useful, but not required, right? The consistency argument from Jason is
growing on me. Merely validating the certificate chain is not sufficient
to establish trust in the device configuration. So, if a $pci_auth_tool
is needed in the flow at all is there a practical difference between:

	$pci_auth_tool cert --device $dev --slot $slot | openssl

...and:

	cat /sys/bus/pci/devices/$dev/certificates/$slot | openssl

On Thu, Feb 19, 2026 at 10:34:55AM +0100, Lukas Wunner wrote:
> On Wed, Feb 18, 2026 at 08:56:14PM -0400, Jason Gunthorpe wrote:
> > And not sure we should be dumping any certs in sysfs if the plan for
> > the other stuff is netlink, it should be consistent I think.
> 
> It has turned out to be super convenient to expose the 8 slots with
> certificate chains in sysfs for direct examination with openssl and
> similar tools, without having to go through netlink.

Honestly, I'm reluctant to add permanent sysfs uAPI just for temporary
debugging. Put it in debugfs.

There should be a tool suite that runs on top of this stuff and
presents a sensible user experiance, with man pages and so on.

Having to find/remember some baroque openssl command line with a
million options is not reasonable for a production kind of
environment.

Jason

On Thu, Feb 19, 2026 at 08:41:19AM -0400, Jason Gunthorpe wrote:
> Kernel auto acceptance is not desirable for the same reasons it is not
> desirable in a TVM.
> 
> If we do some automatic re-accept for RAS/resume it should be strongly
> tied to some target pre-set by the userspace acceptance process - ie
> "the device must present exactly this specific cert chain and nothing
> else", and probably more too since we may want to exclude swapping out
> device FW versions or similar.

The way this works in my series (and I presume Alistair's) is that
trusted root certificates for devices need to be added to the .cma
keyring.

This can be done from user space using keyctl(1) or some other utility
that can talk to the kernel's existing keyctl ABI.

It is also possible to link the .builtin_trusted_keys or .platform
keyrings into the .cma keyring and thereby declare anything trusted
that is used for UEFI Secure Boot.  Likewise blacklisted certificates
added to the .blacklisted keyring are rejected for SPDM device
authentication.  These are existing, well-established roots of trust
in the kernel that CMA simply inherits.  I think it is reasonable
to base auto-acceptance on these existing mechanisms.  No need to
reinvent the wheel.

If you want to trust exactly one specific End Entity certificate,
you could provision an SPDM slot with that certificate, add it to
the .cma keyring and clean out all the other 7 SPDM certificate slots
on the device.

> > It has turned out to be super convenient to expose the 8 slots with
> > certificate chains in sysfs for direct examination with openssl and
> > similar tools, without having to go through netlink.
> 
> Honestly, I'm reluctant to add permanent sysfs uAPI just for temporary
> debugging. Put it in debugfs.

Exposure of the certificates in the SPDM slots is not for debugging,
it's just super convenient for day-to-day use.

> Having to find/remember some baroque openssl command line with a
> million options is not reasonable for a production kind of
> environment.

Personally I find something like the following neither baroque nor
unreasonable:

  # What's the certificate chain in slot0?
  openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0

  # Fingerprint of root cert in slot0, does it match what vendor claims?
  openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0

  # Looks good, let's trust it:
  keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0

> There should be a tool suite that runs on top of this stuff and
> presents a sensible user experiance, with man pages and so on.

Device authentication is currently trickling down from server to
client to embedded/edge devices and you don't want to require users
to install a tool suite on space-constrained embedded devices where
busybox + openssl is otherwise enough, doubly so with skyrocketing
eMMC prices.

Thanks,

Lukas

On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> On Thu, Feb 19, 2026 at 08:41:19AM -0400, Jason Gunthorpe wrote:
> > > It has turned out to be super convenient to expose the 8 slots with
> > > certificate chains in sysfs for direct examination with openssl and
> > > similar tools, without having to go through netlink.
> > 
> > Honestly, I'm reluctant to add permanent sysfs uAPI just for temporary
> > debugging. Put it in debugfs.
> 
> Exposure of the certificates in the SPDM slots is not for debugging,
> it's just super convenient for day-to-day use.
> 
> > Having to find/remember some baroque openssl command line with a
> > million options is not reasonable for a production kind of
> > environment.
> 
> Personally I find something like the following neither baroque nor
> unreasonable:
> 
>   # What's the certificate chain in slot0?
>   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> 
>   # Fingerprint of root cert in slot0, does it match what vendor claims?
>   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> 
>   # Looks good, let's trust it:
>   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0

As much fun as it is to abuse sysfs, please, let's not do this there.
You just did something that could have changed the device between
storing, checking and then trusting it as the device is never guaranteed
to remain the same across multiple calls to sysfs (i.e. yanked out and
another added.)

So let's not design in a security issue from the start please :)

thanks,

greg k-h

On Thu, Feb 19, 2026 at 03:40:25PM +0100, Greg KH wrote:
> On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> >   # What's the certificate chain in slot0?
> >   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > 
> >   # Fingerprint of root cert in slot0, does it match what vendor claims?
> >   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > 
> >   # Looks good, let's trust it:
> >   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> 
> As much fun as it is to abuse sysfs, please, let's not do this there.
> You just did something that could have changed the device between
> storing, checking and then trusting it as the device is never guaranteed
> to remain the same across multiple calls to sysfs (i.e. yanked out and
> another added.)

No, the kernel caches the certificate chains read from the SPDM slots
and what is exposed in sysfs is that cached copy.  So all three commands
above pertain to the same certificate chain.

> So let's not design in a security issue from the start please :)

The alleged security issue does not exist.

Thanks,

Lukas

On Fri, Feb 20, 2026 at 08:46:21AM +0100, Lukas Wunner wrote:
> On Thu, Feb 19, 2026 at 03:40:25PM +0100, Greg KH wrote:
> > On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> > >   # What's the certificate chain in slot0?
> > >   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > 
> > >   # Fingerprint of root cert in slot0, does it match what vendor claims?
> > >   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > 
> > >   # Looks good, let's trust it:
> > >   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > 
> > As much fun as it is to abuse sysfs, please, let's not do this there.
> > You just did something that could have changed the device between
> > storing, checking and then trusting it as the device is never guaranteed
> > to remain the same across multiple calls to sysfs (i.e. yanked out and
> > another added.)
> 
> No, the kernel caches the certificate chains read from the SPDM slots
> and what is exposed in sysfs is that cached copy.  So all three commands
> above pertain to the same certificate chain.

So if a device is removed and a different one added between steps 2 and
three above, with the same pci number, all is ok?

Remember, PCI device ids are not unique, they can come and go and be
reordered and reused at any point in time.  They are fully dynamic and
should NEVER be used as a unique identifier except for a specific moment
in time.

In other words, you are expecting that device id to always refer to the
same device across all 3 operations, which is never guaranteed.

> > So let's not design in a security issue from the start please :)
> 
> The alleged security issue does not exist.

How is this not the classic definition of a TOCTOU (time-of-check to
time-of-use) problem?

thanks,

greg k-h

On Fri, Feb 20, 2026 at 10:14:56AM +0100, Greg KH wrote:
> On Fri, Feb 20, 2026 at 08:46:21AM +0100, Lukas Wunner wrote:
> > On Thu, Feb 19, 2026 at 03:40:25PM +0100, Greg KH wrote:
> > > On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> > > >   # What's the certificate chain in slot0?
> > > >   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > > 
> > > >   # Fingerprint of root cert in slot0, does it match what vendor claims?
> > > >   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > > 
> > > >   # Looks good, let's trust it:
> > > >   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > 
> So if a device is removed and a different one added between steps 2 and
> three above, with the same pci number, all is ok?
> 
> Remember, PCI device ids are not unique, they can come and go and be
> reordered and reused at any point in time.  They are fully dynamic and
> should NEVER be used as a unique identifier except for a specific moment
> in time.
> 
> In other words, you are expecting that device id to always refer to the
> same device across all 3 operations, which is never guaranteed.

If the user chooses to replace the device between steps 2 and 3,
they get to keep the pieces.

Thanks,

Lukas

On Fri, Feb 20, 2026 at 12:45:19PM +0100, Lukas Wunner wrote:
> On Fri, Feb 20, 2026 at 10:14:56AM +0100, Greg KH wrote:
> > On Fri, Feb 20, 2026 at 08:46:21AM +0100, Lukas Wunner wrote:
> > > On Thu, Feb 19, 2026 at 03:40:25PM +0100, Greg KH wrote:
> > > > On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> > > > >   # What's the certificate chain in slot0?
> > > > >   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > > > 
> > > > >   # Fingerprint of root cert in slot0, does it match what vendor claims?
> > > > >   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > > > 
> > > > >   # Looks good, let's trust it:
> > > > >   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > > 
> > So if a device is removed and a different one added between steps 2 and
> > three above, with the same pci number, all is ok?
> > 
> > Remember, PCI device ids are not unique, they can come and go and be
> > reordered and reused at any point in time.  They are fully dynamic and
> > should NEVER be used as a unique identifier except for a specific moment
> > in time.
> > 
> > In other words, you are expecting that device id to always refer to the
> > same device across all 3 operations, which is never guaranteed.
> 
> If the user chooses to replace the device between steps 2 and 3,
> they get to keep the pieces.

So you are saying that is ok to do:
   - test if we trust the fingerprint
   - trust the device of a fingerprint we didn't check

Then why do step 1 here at all?

Perhaps sysfs just isn't the best api here :)

thanks,

greg k-h

On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> On Thu, Feb 19, 2026 at 08:41:19AM -0400, Jason Gunthorpe wrote:
> > Kernel auto acceptance is not desirable for the same reasons it is not
> > desirable in a TVM.
> > 
> > If we do some automatic re-accept for RAS/resume it should be strongly
> > tied to some target pre-set by the userspace acceptance process - ie
> > "the device must present exactly this specific cert chain and nothing
> > else", and probably more too since we may want to exclude swapping out
> > device FW versions or similar.
> 
> The way this works in my series (and I presume Alistair's) is that
> trusted root certificates for devices need to be added to the .cma
> keyring.
> 
> This can be done from user space using keyctl(1) or some other utility
> that can talk to the kernel's existing keyctl ABI.

I really don't like this from a verification perspective. We don't
want the kernel checking signatures, that is the verifier's job.

And a general keyring based proeprty is not at all the same as 'this
device must present exactly the same certification and attesation
after resume'

> authentication.  These are existing, well-established roots of trust
> in the kernel that CMA simply inherits.  I think it is reasonable
> to base auto-acceptance on these existing mechanisms.  No need to
> reinvent the wheel.

It depends what you are building. We've been focused on external
verification so this is not at all desirable.

Something else, maybe some kind of internal verification for embedded
is a quite different story. The two cases still need to compose
sensibly within the kernel though.

> > Having to find/remember some baroque openssl command line with a
> > million options is not reasonable for a production kind of
> > environment.
> 
> Personally I find something like the following neither baroque nor
> unreasonable:
> 
>   # What's the certificate chain in slot0?
>   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> 
>   # Fingerprint of root cert in slot0, does it match what vendor claims?
>   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> 
>   # Looks good, let's trust it:
>   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0

That's exactly the baroque I'm talking about, no server admin is going
to want to grapple with that..

> Device authentication is currently trickling down from server to
> client to embedded/edge devices and you don't want to require users
> to install a tool suite on space-constrained embedded devices where
> busybox + openssl is otherwise enough, doubly so with skyrocketing
> eMMC prices.

Maybe, but is this a real thing where someone would run busybox and
want some minimal self-verification?

Jason

On Thu, Feb 19, 2026 at 10:31:29AM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> > The way this works in my series (and I presume Alistair's) is that
> > trusted root certificates for devices need to be added to the .cma
> > keyring.
> > 
> > This can be done from user space using keyctl(1) or some other utility
> > that can talk to the kernel's existing keyctl ABI.
> 
> I really don't like this from a verification perspective. We don't
> want the kernel checking signatures, that is the verifier's job.

On resume from system sleep, the device is put into D0 already in the
->resume_noirq() phase and drivers are free to access it already at
that point.  However a verifier in user space cannot be queried
at that point because user space is still frozen.

Likewise after recovery from DPC or AER, the device has been reset
and needs to be reauthenticated, yet user space may be unavailable
because the device that has been reset may contain the root partition
or may be the NIC that you need to query your remote attestation service.

There is no way around some form of in-kernel device authentication
to accommodate such use cases.

> And a general keyring based proeprty is not at all the same as 'this
> device must present exactly the same certification and attesation
> after resume'

Well please be constructive and propose something better.

> > authentication.  These are existing, well-established roots of trust
> > in the kernel that CMA simply inherits.  I think it is reasonable
> > to base auto-acceptance on these existing mechanisms.  No need to
> > reinvent the wheel.
> 
> It depends what you are building. We've been focused on external
> verification so this is not at all desirable.

No problem at all.  The kernel will merely use the .cma keyring for
its own notion of an authenticated device.

However if there is no trusted root cert in the .cma keyring,
the kernel will still multicast the signature received from the
device via netlink, so your user space tool can ask the remote
attestation service and if it responds affirmatively, you trust
the device.

So you can either use the .cma keyring for in-kernel authentication
or you can use your user space utility.

But you can't rely on user space if you want seamless re-authentication
after a system sleep transition or error recovery.

We can discuss a way for user space to force the kernel into
considering a device authenticated.  E.g. writing "force" to
the "authenticated" attribute may tell the kernel that it's
a trustworthy device irrespective of the .cma keyring.
So you'd perform remote attestation and if successful,
tell the kernel to consider the device trusted.

> >   # What's the certificate chain in slot0?
> >   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > 
> >   # Fingerprint of root cert in slot0, does it match what vendor claims?
> >   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > 
> >   # Looks good, let's trust it:
> >   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> 
> That's exactly the baroque I'm talking about, no server admin is going
> to want to grapple with that..

I used to be an admin for 2 decades and my experience is that
openssl usage has just become muscle memory, but YMMV. :)

Thanks,

Lukas

On Thu, Feb 19, 2026 at 04:07:58PM +0100, Lukas Wunner wrote:
> On Thu, Feb 19, 2026 at 10:31:29AM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> > > The way this works in my series (and I presume Alistair's) is that
> > > trusted root certificates for devices need to be added to the .cma
> > > keyring.
> > > 
> > > This can be done from user space using keyctl(1) or some other utility
> > > that can talk to the kernel's existing keyctl ABI.
> > 
> > I really don't like this from a verification perspective. We don't
> > want the kernel checking signatures, that is the verifier's job.
> 
> On resume from system sleep, the device is put into D0 already in the
> ->resume_noirq() phase and drivers are free to access it already at
> that point.  However a verifier in user space cannot be queried
> at that point because user space is still frozen.
> 
> Likewise after recovery from DPC or AER, the device has been reset
> and needs to be reauthenticated, yet user space may be unavailable
> because the device that has been reset may contain the root partition
> or may be the NIC that you need to query your remote attestation service.
> 
> There is no way around some form of in-kernel device authentication
> to accommodate such use cases.

I'm arguing there are two very different steps here that must be kept
separate. Verification is done when the device is first seen and the
kernel is told it is OK to use the device.

A same-device check is performed if an already verified and accepted
device resumes or RAS's in some way.

same-device does not mean run a kernel verification against the kernel
keyring, as a second verification could be tricked into accepting
something that has changed and defeat the userspace verifier.

Instead the implementation should capture information when the device
is accepted by the verifier and on resume/RAS it should compare the
device against that captured information and determine if it is still
the same device.

The key north star must be that the userspace verifier alone decides
if the device is acceptable and if the kernel is configured to
auto-re-accept the device later on RAS/resume it must not permit a
device that is different from what userspace approved. In other words
it is not a verification on resume, it is just a kernel side
confirmation the device hasn't been changed.

Hence no keyring should be involved in resume.

I understand the tempatation to just run a kernel verification twice,
and it is OK if your use cases are limited to a kernel verifier, but
it doesn't compose very well with a userspace verfier at all and gives
us two very different frameworks.

> > And a general keyring based proeprty is not at all the same as 'this
> > device must present exactly the same certification and attesation
> > after resume'
> 
> Well please be constructive and propose something better.

I have said what I'd like in a few ways now.

> We can discuss a way for user space to force the kernel into
> considering a device authenticated.  E.g. writing "force" to
> the "authenticated" attribute may tell the kernel that it's
> a trustworthy device irrespective of the .cma keyring.
> So you'd perform remote attestation and if successful,
> tell the kernel to consider the device trusted.

We definitely need to ensure we build something where userspace is in
fully in charge.

I don't have an objection to an optional, useful for embedded, kernel
side verifier that uses the cma ring.

What I'm focusing on is that it be coherent with the whole complex
verifier flows we need, not just its own seperate different thing. So
replacing the userspace verifier with a kernel verifier is no
issue. Making it so you HAVE to use the kernel verifier to get certain
functionality like RAS is objectionable.

> > >   # What's the certificate chain in slot0?
> > >   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > 
> > >   # Fingerprint of root cert in slot0, does it match what vendor claims?
> > >   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > 
> > >   # Looks good, let's trust it:
> > >   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > 
> > That's exactly the baroque I'm talking about, no server admin is going
> > to want to grapple with that..
> 
> I used to be an admin for 2 decades and my experience is that
> openssl usage has just become muscle memory, but YMMV. :)

This is also not a very realistic scenario, there is no point to copy
a certificate from a device into the cma key ring. If you want to
trust the device as is without any verification then just accept it as
is with a trivial userspace "verifier".

If you want a kernel side verifier the realistic scenario is to bake
the permitted certificates into the image or kernel and/or have
busybox load them into the keyring at boot.

Jaason

On Thu, Feb 19, 2026 at 01:39:37PM -0400, Jason Gunthorpe wrote:
> I'm arguing there are two very different steps here that must be kept
> separate. Verification is done when the device is first seen and the
> kernel is told it is OK to use the device.
> 
> A same-device check is performed if an already verified and accepted
> device resumes or RAS's in some way.
[...]
> Hence no keyring should be involved in resume.

No, that doesn't work.  You cannot rely on information that the device
presents.  The information may be spoofed.  The only secure way to
ascertain that the device you're talking to is what it purports to be
is to ask it for a signature and verify that the signature was made
with a device certificate which is signed by a root certificate
that you trust.  And the way to trust that root certificate is to
add it to a keyring.

There is no way around that.  What you have in mind could be achieved
by generating a secret token after first authentication and then using
that secret token after RAS / resume for re-authentication.  But I just
looked through the SPDM spec and it doesn't support that kind of thing.

A userspace verifier is incompatible with authentication after RAS
and resume.  It's a technical limitation that you'll have to live with,
I'm sorry.  If you could come up with, say, an eBPF verifier that
user space loads into the kernel, that might be a workable solution.

> I don't have an objection to an optional, useful for embedded, kernel
> side verifier that uses the cma ring.

Good.  My patches merely aim to be a spec-compliant implementation of
PCIe r7.0 sec 6.31 (Component Measurement and Authentication/SPDM).

That spec section does not talk about user space verifiers.

Moreover PCIe r6.1 page 115 states "CMA requires SPDM Version 1.0 or
above", so the baseline that we need to support for spec compliance
is the oldest spec version with the least features.  So even if a
future spec version introduced a feature to establish a shared secret
on first authentication and use that for subsequent authentication,
we'd still be constrained by the SPDM 1.0 feature set for compliance
with older devices.

> > > >   # What's the certificate chain in slot0?
> > > >   openssl storeutl -text /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > > 
> > > >   # Fingerprint of root cert in slot0, does it match what vendor claims?
> > > >   openssl x509 -fingerprint -in /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> > > > 
> > > >   # Looks good, let's trust it:
> > > >   keyctl padd asymmetric "" %:.cma < /sys/bus/pci/devices/0000:03:00.0/certificates/slot0
> 
> This is also not a very realistic scenario, there is no point to copy
> a certificate from a device into the cma key ring. If you want to
> trust the device as is without any verification then just accept it as
> is with a trivial userspace "verifier".

No, in the above example the device is not trusted "as is without any
verification".  The verification that happens above is a manual
comparison of the fingerprint with one provided by the vendor.

Thanks,

Lukas

On Fri, Feb 20, 2026 at 09:30:50AM +0100, Lukas Wunner wrote:
> On Thu, Feb 19, 2026 at 01:39:37PM -0400, Jason Gunthorpe wrote:
> > I'm arguing there are two very different steps here that must be kept
> > separate. Verification is done when the device is first seen and the
> > kernel is told it is OK to use the device.
> > 
> > A same-device check is performed if an already verified and accepted
> > device resumes or RAS's in some way.
> [...]
> > Hence no keyring should be involved in resume.
> 
> No, that doesn't work.  You cannot rely on information that the device
> presents.  The information may be spoofed.  The only secure way to
> ascertain that the device you're talking to is what it purports to be
> is to ask it for a signature and verify that the signature was made
> with a device certificate which is signed by a root certificate
> that you trust.

Yes, and in the most general case the nonce/etc for this must come
through userspace from an external verifier agent.

>  And the way to trust that root certificate is to
> add it to a keyring.

Not quite, the way to have a *kernel verifier* is to have a kernel
verifier use the cma keyring in this way. If you use a userspace
verifier the kernel keyring has no role.

> There is no way around that.  What you have in mind could be achieved
> by generating a secret token after first authentication and then using
> that secret token after RAS / resume for re-authentication.  But I just
> looked through the SPDM spec and it doesn't support that kind of
> thing.

The kernel just records the information the device presented and
checks it is the same. Yes on the same-device check it will have to
make a new nonce and push it through, but it is only checking the
results against the previously cached information for this device, not
a general keyring.

> A userspace verifier is incompatible with authentication after RAS
> and resume.  It's a technical limitation that you'll have to live with,
> I'm sorry.  If you could come up with, say, an eBPF verifier that
> user space loads into the kernel, that might be a workable solution.

You are ignoring the proposal - the idea is to NOT VERIFY on resume,
but to only do a same-device check.

A same-device check should have no policy components that require a
verifier. It gives the device a new fresh nonce, obtains a new
signature, checks the signature works with the previously cached
public key(s).

IOW the resume/RAS acceptance criteria is that the second nonce was
signed with the same private key(s) that the first nonce was signed
with.

In many devices this will be entirely sufficient. It should be common
that each physical device has a unique private key with a certificate
chain to the manufactures secured certificate. Since the private key
is globally unique proving the device has it during resume is the
majority of a same-device check.

From there the kernel can do additional checks, sanity check the
presented certificate list is exactly the same, check the attestation
report hasn't changed to ensure the device hasn't been replaced with
an insecure dowrev or something. (possibly the driver will have to
provide some helper to same-device check its attestation report)

No need for spec changes, no need for a key ring, very different flow
from verification.

The kernel should simply monitor the signature requests from the
verifier, internally confirm the reply is correct and record all the
public keys that were successfully used on this struct device.

> That spec section does not talk about user space verifiers.

Linux will have its own sw model, the spec is just the protocol
definition. In the CC world everyone just knows the verifier needs to
be external.. How else could it even work?

> > This is also not a very realistic scenario, there is no point to copy
> > a certificate from a device into the cma key ring. If you want to
> > trust the device as is without any verification then just accept it as
> > is with a trivial userspace "verifier".
> 
> No, in the above example the device is not trusted "as is without any
> verification".  The verification that happens above is a manual
> comparison of the fingerprint with one provided by the vendor.

"manual comparision" is some debugging flow, like I pointed out at the
start.

Jason

On Fri, Feb 20, 2026 at 10:10:57AM -0400, Jason Gunthorpe wrote:
> IOW the resume/RAS acceptance criteria is that the second nonce was
> signed with the same private key(s) that the first nonce was signed
> with.

What you seem to have in mind is essentially a "trust on first use"
model where trust is given to a specific device certificate
(i.e. leaf certificate), not to a root certificate.

Whereas the SPDM spec (and by extension CMA, i.e. PCIe r7.0 sec 6.31)
envisions a model where each of the 8 slots may contain a certificate
*chain* (comprising a root certificate, optional intermediate certificates
and a leaf certificate).  In this model, trust is given to root
certificates.  These could be vendors, but it's also possible that
e.g. a CSP operates its own CA and provisions one of the 8 slots with
a custom certificate chain anchored in its own CA.

Your "trust on first use" model could be made to fit into the
SPDM model by adding the leaf certificate (= device certificate)
to the .cma keyring and provisioning one of the certificate slots
with just the leaf certificate (and nothing else in the cert chain).
The verifier in user space could add the leaf certificate to the keyring
and provision a slot with it after having verified the device successfully.

That would make verification in user space compatible with RAS & resume,
at least the certificate validation part.

An alternative solution would be to have the verifier in user space
operate its own mini CA.  The root certificate of that mini CA would be
added to the .cma keyring.  Upon successful verification, the verifier
would create a short-lived certificate for the device which is signed
by its mini CA.  The verifier would provision one of the 8 cert slots
of the device with this custom short-lived certificate and thereby
allow the kernel to re-authenticate the device without reliance on
user space until the short-lived certificate expires.  User space
would have to monitor expiration of those certificates and re-new
them to ensure continued re-authentication.

I'm adding Mathieu and Thomas to cc as they have been exploring ways
to take advantage of the .cma keyring for Confidential Computing
use cases.

> Linux will have its own sw model, the spec is just the protocol
> definition. In the CC world everyone just knows the verifier needs to
> be external.. How else could it even work?

There are products out there which support CMA but not TDISP.
In other words, the CC world isn't everything.  The modest goal
of this series is to allow authentication of devices in compliance
with PCIe r7.0 sec 6.31 and the SPDM spec.  I understand there are
features and authentication modes which are important for the
Confidential Computing world, but CoCo needs to fit into the
spec-defined mechanisms.

Thanks,

Lukas

On Sat, Feb 21, 2026 at 07:46:09PM +0100, Lukas Wunner wrote:
> On Fri, Feb 20, 2026 at 10:10:57AM -0400, Jason Gunthorpe wrote:
> > IOW the resume/RAS acceptance criteria is that the second nonce was
> > signed with the same private key(s) that the first nonce was signed
> > with.
> 
> What you seem to have in mind is essentially a "trust on first use"
> model where trust is given to a specific device certificate
> (i.e. leaf certificate), not to a root certificate.

Not really, please read my email again.

I said userspace does the verification, using all the certificate
chains and beyond. Then once verified the kernel only does a 'same
device' check that ensures the device hasn't changed from what was
originally verified.

Spec supports this just fine.

> certificates.  These could be vendors, but it's also possible that
> e.g. a CSP operates its own CA and provisions one of the 8 slots with
> a custom certificate chain anchored in its own CA.

And the userspace verifier is free to check all of this.

> An alternative solution would be to have the verifier in user space
> operate its own mini CA.  The root certificate of that mini CA would be
> added to the .cma keyring.  

No! Why are you trying to massively over complicate this? The proposal
is very simple :(

> > Linux will have its own sw model, the spec is just the protocol
> > definition. In the CC world everyone just knows the verifier needs to
> > be external.. How else could it even work?
> 
> There are products out there which support CMA but not TDISP.

Sure, but that doesn't mean anything for verification.

Most models I've seen for using this stuff are "cloud connected"
things where the cloud is going to measure and attest the end device
before giving it anything sensitive.

That's remote verification, and what you absolutely don't want is some
way for the attacker to pass remote verification, then replace the
device and somehow pass a much weaker local only verification and
attack the security.

This is why I'm insistent the starting point for resmue is a very
strong same-device check that prevents attackers from replacing the
device with something that wouldn't pass remote verification.

If you don't do this and instead try to revalidate the certificate
chains the kernel can be tricked into accepting a different device on
resume and that will completely destroy the entire security model.

> In other words, the CC world isn't everything.  The modest goal
> of this series is to allow authentication of devices in compliance
> with PCIe r7.0 sec 6.31 and the SPDM spec.  

As Dan and I keep saying you should focus on enabling userspace
verifier as the very first modest step and then come with proposals to
add additional things like resume and perhaps a kernel-internal
verifier.

I don't see a role for a cma keyring outside a kernel-internel
verifier (and I'm skeptical this is desirable in the first place since
a userspace implementation would not be such a burden)

Jason

On Tue, Feb 24, 2026 at 10:16:10AM -0400, Jason Gunthorpe wrote:
> This is why I'm insistent the starting point for resmue is a very
> strong same-device check that prevents attackers from replacing the
> device with something that wouldn't pass remote verification.
> 
> If you don't do this and instead try to revalidate the certificate
> chains the kernel can be tricked into accepting a different device on
> resume and that will completely destroy the entire security model.

Finding a different device on resume is par for the course for hotplug.

> As Dan and I keep saying you should focus on enabling userspace
> verifier as the very first modest step and then come with proposals to
> add additional things like resume and perhaps a kernel-internal
> verifier.

There is nothing to "add".  Seamless re-verification on resume and
error recovery is already implemented in my patches.  I don't see
the point of throwing that out the window and start from scratch
just because you think it doesn't have priority.

> I don't see a role for a cma keyring outside a kernel-internel
> verifier

That sounds like we have minimal consensus.

I'm coming from a very different direction, I want this to seamlessly
integrate with all the infrastructure we already have in the PCI core
(hotplug, suspend/resume, error recovery, ...), so I made sure it does.

I don't share the view that CMA is merely a building block for TDISP.
It's useful on its own.

I also believe that the vast majority of users will simply need this
to ensure the devices they attach to their chromebooks, phones etc
are authentic (seems important given the reports of counterfeit
hard drives).  A .cma keyring is good enough for Grandma's chromebook,
no need for a user space verifier.

Thanks,

Lukas

On Tue, Feb 24, 2026 at 04:54:15PM +0100, Lukas Wunner wrote:
> On Tue, Feb 24, 2026 at 10:16:10AM -0400, Jason Gunthorpe wrote:
> > This is why I'm insistent the starting point for resmue is a very
> > strong same-device check that prevents attackers from replacing the
> > device with something that wouldn't pass remote verification.
> > 
> > If you don't do this and instead try to revalidate the certificate
> > chains the kernel can be tricked into accepting a different device on
> > resume and that will completely destroy the entire security model.
> 
> Finding a different device on resume is par for the course for hotplug.

And? The point is we must detect and reject this as a matter of
security.
 
> > As Dan and I keep saying you should focus on enabling userspace
> > verifier as the very first modest step and then come with proposals to
> > add additional things like resume and perhaps a kernel-internal
> > verifier.
> 
> There is nothing to "add".  Seamless re-verification on resume and
> error recovery is already implemented in my patches.  I don't see
> the point of throwing that out the window and start from scratch
> just because you think it doesn't have priority.

The objection is it doesn't implement a sufficient security model, and
I'm strongly arguing you have built the wrong thing.

The suggested path is not about priority, but to follow the path of
consense where we all agree a userspace verifier is a required
component, so we should start with the parts we all agree on and
incrementally work on the dis-agreed parts.

Saying I already built it so I should get to merge it is not
constructive.

> I'm coming from a very different direction, I want this to seamlessly
> integrate with all the infrastructure we already have in the PCI core
> (hotplug, suspend/resume, error recovery, ...), so I made sure it does.

Well, this is security work. Linking a bunch of stuff together without
having a clear threat model and desired seurity properties is not the
right approach at all.

The kernel needs to enforce security properties and present a
consistent threat model, and what you have done is inconsisent and
weaker than the models we do want to build.

It also seems all your use cases fit within the broder models, so I
don't see why we should enshrine a bad security model in the kernel,
as UAPI at this point.
 
> I don't share the view that CMA is merely a building block for TDISP.
> It's useful on its own.

I agree it is useful on its own, but when used without TDISP we still
want to have the same basic threat model and overall security posture,
it is not an excusse to just weaken everything.

We are looking at building CMA based, non-TDISP systems that need all
the stuff I'm talking about.

> I also believe that the vast majority of users will simply need this
> to ensure the devices they attach to their chromebooks, phones etc
> are authentic (seems important given the reports of counterfeit
> hard drives).  A .cma keyring is good enough for Grandma's chromebook,
> no need for a user space verifier.

A chromebook has no issue to run a userspace verifier, and overall the
kernel community prefers to put things to userspace whenever possible.

Given a userspace solution will have to exist I think you have a
fairly high bar to cross to propose duplicating it into the kernel,
which is why it should come after the userspace path is setup so it
can be properly explained and justified.

Jason

Lukas Wunner wrote:
> On Fri, Feb 20, 2026 at 10:10:57AM -0400, Jason Gunthorpe wrote:
> > IOW the resume/RAS acceptance criteria is that the second nonce was
> > signed with the same private key(s) that the first nonce was signed
> > with.
[..]
> > Linux will have its own sw model, the spec is just the protocol
> > definition. In the CC world everyone just knows the verifier needs to
> > be external.. How else could it even work?
> 
> There are products out there which support CMA but not TDISP.
> In other words, the CC world isn't everything.  The modest goal
> of this series is to allow authentication of devices in compliance
> with PCIe r7.0 sec 6.31 and the SPDM spec.  I understand there are
> features and authentication modes which are important for the
> Confidential Computing world, but CoCo needs to fit into the
> spec-defined mechanisms.

The TDISP proposal from Jason and I bears repeating because it is a
superset of what a CMA-only solution needs, and security guarantees it
provides. I also submit that "identity revalidation over reset/resume"
is not a *primary* concern. It is certainly *a* concern that needs to be
part of the ongoing discussion to avoid painting ourselves into a
corner, but certainly a complexity that is incremental to the base
enabling. Recall CMA is only a building block to trusting the rest of
the device interface outside of the SPDM session.

Userspace is in charge of all trust and verification decisions. A TSM
driver, whether that driver is in-kernel-SPDM-library, or platform TSM,
establishes a session with a device with a given certificate slot. The
session establishment makes cert-chain+transcript available to userspace
and caches the public-key. If userspace does not like that result, it
opts to not bind a driver to that device, or retries with a different
cert slot.

If later we want to support a "same device" capability in scenarios
where a userspace round trip is infeasible then that is incremental ABI.
That ABI would allow userspace to cache golden cert-chain+measurements.
The resume path can revalidate that identity description with a fresh
nonce and the cached public key.

For TDISP the violence of dropping the device out of the TCB likely
needs more sophistication than golden measurement revalidation. For CMA
mere trust in the root cert is not sufficient for many of the
adversarial device threat models, so the kernel need not carry that
responsibility.

Aneesh and I are putting together some POC patches along these lines.

On Sat, 21 Feb 2026 15:29:55 -0800
dan.j.williams@intel.com wrote:

> Lukas Wunner wrote:
> > On Fri, Feb 20, 2026 at 10:10:57AM -0400, Jason Gunthorpe wrote:  
> > > IOW the resume/RAS acceptance criteria is that the second nonce was
> > > signed with the same private key(s) that the first nonce was signed
> > > with.  
> [..]
> > > Linux will have its own sw model, the spec is just the protocol
> > > definition. In the CC world everyone just knows the verifier needs to
> > > be external.. How else could it even work?  
> > 
> > There are products out there which support CMA but not TDISP.
> > In other words, the CC world isn't everything.  The modest goal
> > of this series is to allow authentication of devices in compliance
> > with PCIe r7.0 sec 6.31 and the SPDM spec.  I understand there are
> > features and authentication modes which are important for the
> > Confidential Computing world, but CoCo needs to fit into the
> > spec-defined mechanisms.  
> 
> The TDISP proposal from Jason and I bears repeating because it is a
> superset of what a CMA-only solution needs, and security guarantees it
> provides. I also submit that "identity revalidation over reset/resume"
> is not a *primary* concern. It is certainly *a* concern that needs to be
> part of the ongoing discussion to avoid painting ourselves into a
> corner, but certainly a complexity that is incremental to the base
> enabling. Recall CMA is only a building block to trusting the rest of
> the device interface outside of the SPDM session.
> 
> Userspace is in charge of all trust and verification decisions. A TSM
> driver, whether that driver is in-kernel-SPDM-library, or platform TSM,
> establishes a session with a device with a given certificate slot. The
> session establishment makes cert-chain+transcript available to userspace
> and caches the public-key. If userspace does not like that result, it
> opts to not bind a driver to that device, or retries with a different
> cert slot.
> 
> If later we want to support a "same device" capability in scenarios
> where a userspace round trip is infeasible then that is incremental ABI.
> That ABI would allow userspace to cache golden cert-chain+measurements.
> The resume path can revalidate that identity description with a fresh
> nonce and the cached public key.

From a simple case of 'what is here' in this set, the only bit I'm seeing
change in order to implement what I think you and Jason are describing is we
don't bother checking the cert chain in kernel for the first time: We
provide that to userspace to decide if it's good. If I understand
correctly, this will be at the end of the full sequence once we've pushed
through a nonce and gotten signatures + measurements.  Same as checking a
TSM provided transcript. That was sort of happening anyway if we consider
the .cma keyring as just providing a short cut filter if we didn't trust
the device provided root cert.
User space got the transcripts before it had to make any decision on
binding and could do anything it liked with them.

For that caching the public key bit, I'm not clear on whether you intend
to do that from kernel side (which I think I'd prefer) or have user space
squirt that key back in again?  If we are doing it in kernel we can
at least always verify the transcript is self consistent and refuse to
give anything to user space if it's not consistent (other than debug material).
By self consistent I mean we verify the signature against the device provided
cert (might as well verify whole chain as that's trivial given we have to partly
parse them anyway to find the cert).  I don't think it maters hugely if
we do this in kernel beyond advantage of removing a few foot guns and
simplifying the userpace interface to "I'm fine with the provided transcript
for use when I'm not here next time" write. Disadvantage is we use the
cert parsing code (which is there anyway) and parse it all twice - once
in kernel and probably again in userspace or at some remote verifier.

Measurement verification (in kernel) is potentially a trickier bit of ABI
design as the space of what might be in there and what matters for a given
device is complex to say the least.  Only a small part of that is spec
defined.

I can see there may be some use cases where we relax things beyond this
(potentially including .cma keyring and root cert only)

Jonathan


> 
> For TDISP the violence of dropping the device out of the TCB likely
> needs more sophistication than golden measurement revalidation. For CMA
> mere trust in the root cert is not sufficient for many of the
> adversarial device threat models, so the kernel need not carry that
> responsibility.
> 
> Aneesh and I are putting together some POC patches along these lines.
> 
> 

Jonathan Cameron wrote:
[..] 
> From a simple case of 'what is here' in this set, the only bit I'm seeing
> change in order to implement what I think you and Jason are describing is we
> don't bother checking the cert chain in kernel for the first time: We
> provide that to userspace to decide if it's good. If I understand
> correctly, this will be at the end of the full sequence once we've pushed
> through a nonce and gotten signatures + measurements.  Same as checking a
> TSM provided transcript. That was sort of happening anyway if we consider
> the .cma keyring as just providing a short cut filter if we didn't trust
> the device provided root cert.
> User space got the transcripts before it had to make any decision on
> binding and could do anything it liked with them.

Exactly, the kernel checking the cert is not sufficient to establish
trust in the device interface (Link + MMIO). If userspace is making a
driver-bind or TDISP accept decision, it needs
certs+measurements+interface-report and does not benefit from the kernel
also validating the certificate.

> For that caching the public key bit, I'm not clear on whether you intend
> to do that from kernel side (which I think I'd prefer) or have user space
> squirt that key back in again?  If we are doing it in kernel we can
> at least always verify the transcript is self consistent and refuse to
> give anything to user space if it's not consistent (other than debug material).
> By self consistent I mean we verify the signature against the device provided
> cert (might as well verify whole chain as that's trivial given we have to partly
> parse them anyway to find the cert).  I don't think it maters hugely if
> we do this in kernel beyond advantage of removing a few foot guns and
> simplifying the userpace interface to "I'm fine with the provided transcript
> for use when I'm not here next time" write. Disadvantage is we use the
> cert parsing code (which is there anyway) and parse it all twice - once
> in kernel and probably again in userspace or at some remote verifier.

Right, the proposal is cache the public-key from pci_tsm_ops::connect()
and at least require that the resulting transcript from that session
establishment is properly self-signed. No point in continuing with a TSM
implementation that is not self-consistent.

> Measurement verification (in kernel) is potentially a trickier bit of ABI
> design as the space of what might be in there and what matters for a given
> device is complex to say the least.  Only a small part of that is spec
> defined.
> 
> I can see there may be some use cases where we relax things beyond this
> (potentially including .cma keyring and root cert only)

So I expect there will be an extended tail of problems to solve from
same device and same measurements checks, to full recovery into the TCB.
A .cma keyring may be a part of that eventually, but the "as simple as
possible, but no simpler" starting point is userspace device policy
wrapped around self-signed evidence.

If the device interface is adversarial, mere trust in the SPDM session
is insufficient to protect against the type of attacks that re-checking
the certificate only after reset/resume is meant to mitigate.

dan.j.williams@ wrote:
[..]
> > For that caching the public key bit, I'm not clear on whether you intend
> > to do that from kernel side (which I think I'd prefer) or have user space
> > squirt that key back in again?  If we are doing it in kernel we can
> > at least always verify the transcript is self consistent and refuse to
> > give anything to user space if it's not consistent (other than debug material).
> > By self consistent I mean we verify the signature against the device provided
> > cert (might as well verify whole chain as that's trivial given we have to partly
> > parse them anyway to find the cert).  I don't think it maters hugely if
> > we do this in kernel beyond advantage of removing a few foot guns and
> > simplifying the userpace interface to "I'm fine with the provided transcript
> > for use when I'm not here next time" write. Disadvantage is we use the
> > cert parsing code (which is there anyway) and parse it all twice - once
> > in kernel and probably again in userspace or at some remote verifier.
> 
> Right, the proposal is cache the public-key from pci_tsm_ops::connect()
> and at least require that the resulting transcript from that session
> establishment is properly self-signed. No point in continuing with a TSM
> implementation that is not self-consistent.

So I ended up dropping this bit of the proposal because there is no need
for the kernel to be involved in any decision about the validity and
sufficiency of device evidence. Userspace has everything it needs to
make that initial determination. "Authenticated" simply means "evidence
ready".

Automatic device recovery into the TCB is a separate concern that needs
to be prepared to handle more than just "is this device able to generate
a fresh signature with the same cert chain that userspace saw before".
Yes, that is a minimal requirement but not sufficient for many cases.
For example cases that want to validate measurements, interface reports,
or opt-out of recovery because SPDM session loss is fatal.

I had a chat with Lukas about what I think that looks like this morning
and offered to summarize that in this thread. Note, this description is
assuming the drivers/pci/tsm/evidence.c implementation started here [1].

[1]: http://lore.kernel.org/20260303000207.1836586-9-dan.j.williams@intel.com

Authenticate a device
=====================
Look in /sys/class/tsm to find a tsmN device which will be either an
instance associated with native kernel PCI CMA/SPDM or a platform tsm
like the one provided by AMD SEV-TIO, ARM CCA, Intel TDX, etc...

echo tsmN > /sys/bus/pci/devices/$device/tsm/connect

Once that succeeds the PCI/TSM evidence netlink interface is available
to dump any signatures created during that session establishment.

After userspace is happy with that evidence it can bind a driver.

If running in a confidential VM where the TSM driver is capable of
securing more than just an SPDM session the interface is:

echo tsmN > /sys/bus/pci/devices/$device/tsm/lock

Similar evidence can be collected, and when userspace is happy with it
it can accept the device:

echo 1 > /sys/bus/pci/devices/$device/tsm/accept

...and bind a driver.

Auto-recover device (future work)
=================================
By default, devices fall out of the TCB on recovery events for the TDISP
case and need userspace to rerun the lock and accept flow. For the
native SPDM CMA case the default is that the kernel continues to operate
the device post recovery and only userspace polling could detect device
replacement.

To go beyond those defaults the kernel needs userpsace to tell it how to
re-validate the device. I think that can be as simple as a netlink
message to store hashes of cert chains or measurements and then use
those in a new challenge / response with the device with a kernel
decided nonce. It can also be more sophisiticated than that. The
point is that it will be use case dependendent, policy driven, and
separate from the "connect" or "lock" flow.

The equivalent behavior to what is present in this SPDM proposal is
extend drivers/pci/tsm/evidence.c to add a netlink operation that tells
the kernel to cache the public-key and challenge the device regenerate a
valid signature. Then plumb all the recovery paths to call a new
'struct pci_tsm_ops::revalidate()' operation in all the same places
where this patch set wants to reauthenticate. Later when something more
sophisticated than "challenge the device to create a signature" comes
along it can reuse those revalidate() hooks.

Auto-authenticate devices (future work)
=======================================
One of the nice aspects of the .cma keyring proposal is that it would be
amenable to CONFIG_SYSTEM_EXTRA_CERTIFICATE. Give the kernel the
certificate to validate device signatures without needing to ask
userspace. That still comes with the caveat that it is not sufficient
for the cases that care about more than mere signature verification. I
am not opposed to that being built just that it is not a policy that is
implied by the device "authenticated" state. It is policy that is
incremental to the base which makes no assumptions about kernel
verification.

On Wed, Mar 04, 2026 at 08:17:24PM -0800, dan.j.williams@intel.com wrote:

> So I ended up dropping this bit of the proposal because there is no need
> for the kernel to be involved in any decision about the validity and
> sufficiency of device evidence. Userspace has everything it needs to
> make that initial determination. "Authenticated" simply means "evidence
> ready".

Right, this caching was only for the automatic device recovery flow.

I think the kernel still probably needs to check the signed nonce
against the device's public key as part of the SPDM handshake, but it
doesn't need to do any validation of the public key.

> Automatic device recovery into the TCB is a separate concern that needs
> to be prepared to handle more than just "is this device able to generate
> a fresh signature with the same cert chain that userspace saw before".
> Yes, that is a minimal requirement but not sufficient for many cases.
> For example cases that want to validate measurements, interface reports,
> or opt-out of recovery because SPDM session loss is fatal.

Yeah, but it is a pretty good starting point :)

> Authenticate a device
> =====================
> Look in /sys/class/tsm to find a tsmN device which will be either an
> instance associated with native kernel PCI CMA/SPDM or a platform tsm
> like the one provided by AMD SEV-TIO, ARM CCA, Intel TDX, etc...
> 
> echo tsmN > /sys/bus/pci/devices/$device/tsm/connect
> 
> Once that succeeds the PCI/TSM evidence netlink interface is available
> to dump any signatures created during that session establishment.
> 
> After userspace is happy with that evidence it can bind a driver.
> 
> If running in a confidential VM where the TSM driver is capable of
> securing more than just an SPDM session the interface is:
> 
> echo tsmN > /sys/bus/pci/devices/$device/tsm/lock
> 
> Similar evidence can be collected, and when userspace is happy with it
> it can accept the device:
> 
> echo 1 > /sys/bus/pci/devices/$device/tsm/accept
> 
> ...and bind a driver.

Makes sense to me, userspace can figure out what flow to use.

> Auto-recover device (future work)
> =================================
> By default, devices fall out of the TCB on recovery events for the TDISP
> case and need userspace to rerun the lock and accept flow. For the
> native SPDM CMA case the default is that the kernel continues to operate
> the device post recovery and only userspace polling could detect device
> replacement.

Even with SPDM the kernel should know if the SPDM session has to be
restarted right? It could squirt out a netlink multicast message, or a
uevent on these events, so the polling is not baked into the
architecture?

> To go beyond those defaults the kernel needs userpsace to tell it how to
> re-validate the device. I think that can be as simple as a netlink
> message to store hashes of cert chains or measurements and then use
> those in a new challenge / response with the device with a kernel
> decided nonce.

Yeah, I see several reasonable options:

1) Above, kernel is informed of hashes and does an exact content
   compare

2) The driver operating the device has a built in same-device policy
   and deep parses the evidence for equivilance after the private key
   is validated, carefully avoiding volatile evidence bytes.

3) User provides a BPF program and it runs on the evidence

4) Standards bodies define a generic "same device check" algorithm for
   the evidence and core kernel just does this for compatible devices

> The equivalent behavior to what is present in this SPDM proposal is
> extend drivers/pci/tsm/evidence.c to add a netlink operation that tells
> the kernel to cache the public-key and challenge the device regenerate a
> valid signature. Then plumb all the recovery paths to call a new
> 'struct pci_tsm_ops::revalidate()' operation in all the same places
> where this patch set wants to reauthenticate. Later when something more
> sophisticated than "challenge the device to create a signature" comes
> along it can reuse those revalidate() hooks.

That's a nice simple starting point.

> Auto-authenticate devices (future work)
> =======================================
> One of the nice aspects of the .cma keyring proposal is that it would be
> amenable to CONFIG_SYSTEM_EXTRA_CERTIFICATE. Give the kernel the
> certificate to validate device signatures without needing to ask
> userspace. That still comes with the caveat that it is not sufficient
> for the cases that care about more than mere signature verification. I
> am not opposed to that being built just that it is not a policy that is
> implied by the device "authenticated" state. It is policy that is
> incremental to the base which makes no assumptions about kernel
> verification.

I have no specific objection to this, and we have many example of
kernel having built-in policy with an option for userspace to take
control. But I'd like to hear a solid reason for a use case that
requires it. I don't really buy the argument that userspace is too
much flash consumption if all the implementation is doing is checking
a few certs using an already present TLS library.

Jason

Jason Gunthorpe wrote:
> On Wed, Mar 04, 2026 at 08:17:24PM -0800, dan.j.williams@intel.com wrote:
> 
> > So I ended up dropping this bit of the proposal because there is no need
> > for the kernel to be involved in any decision about the validity and
> > sufficiency of device evidence. Userspace has everything it needs to
> > make that initial determination. "Authenticated" simply means "evidence
> > ready".
> 
> Right, this caching was only for the automatic device recovery flow.
> 
> I think the kernel still probably needs to check the signed nonce
> against the device's public key as part of the SPDM handshake, but it
> doesn't need to do any validation of the public key.

Yes, and I think this is a subtle detail that I was failing to grok /
communicate previously. Of course the native SPDM implementation needs
to be able to perform a challenge response to establish the session. All
of the platform TSMs also internally carry out that protocol. The
difference with platform TSMs being that the kernel only sees the
resulting evidence.

So when / if the PCI/TSM evidence implementation grows kernel-internal
revalidate support it will be growing something like pdev->tsm->pubkey
that is installed / cached "after the fact" for platform TSMs. For the
native SPDM driver, pdev->tsm->pubkey can be installed at 'struct
pci_tsm_ops::connect()' time because it already has it parsed for its
own internal purposes.

> > Automatic device recovery into the TCB is a separate concern that needs
> > to be prepared to handle more than just "is this device able to generate
> > a fresh signature with the same cert chain that userspace saw before".
> > Yes, that is a minimal requirement but not sufficient for many cases.
> > For example cases that want to validate measurements, interface reports,
> > or opt-out of recovery because SPDM session loss is fatal.
> 
> Yeah, but it is a pretty good starting point :)
> 
> > Authenticate a device
> > =====================
> > Look in /sys/class/tsm to find a tsmN device which will be either an
> > instance associated with native kernel PCI CMA/SPDM or a platform tsm
> > like the one provided by AMD SEV-TIO, ARM CCA, Intel TDX, etc...
> > 
> > echo tsmN > /sys/bus/pci/devices/$device/tsm/connect
> > 
> > Once that succeeds the PCI/TSM evidence netlink interface is available
> > to dump any signatures created during that session establishment.
> > 
> > After userspace is happy with that evidence it can bind a driver.
> > 
> > If running in a confidential VM where the TSM driver is capable of
> > securing more than just an SPDM session the interface is:
> > 
> > echo tsmN > /sys/bus/pci/devices/$device/tsm/lock
> > 
> > Similar evidence can be collected, and when userspace is happy with it
> > it can accept the device:
> > 
> > echo 1 > /sys/bus/pci/devices/$device/tsm/accept
> > 
> > ...and bind a driver.
> 
> Makes sense to me, userspace can figure out what flow to use.
> 
> > Auto-recover device (future work)
> > =================================
> > By default, devices fall out of the TCB on recovery events for the TDISP
> > case and need userspace to rerun the lock and accept flow. For the
> > native SPDM CMA case the default is that the kernel continues to operate
> > the device post recovery and only userspace polling could detect device
> > replacement.
> 
> Even with SPDM the kernel should know if the SPDM session has to be
> restarted right? It could squirt out a netlink multicast message, or a
> uevent on these events, so the polling is not baked into the
> architecture?

Right, "SPDM session lost" is a reasonable notification to put into the
interface and "future work" bucket. The polling comment was with respect
to the near term limitation of this minimally viable first step.

> > To go beyond those defaults the kernel needs userpsace to tell it how to
> > re-validate the device. I think that can be as simple as a netlink
> > message to store hashes of cert chains or measurements and then use
> > those in a new challenge / response with the device with a kernel
> > decided nonce.
> 
> Yeah, I see several reasonable options:

+1 to these.

> 1) Above, kernel is informed of hashes and does an exact content
>    compare
> 
> 2) The driver operating the device has a built in same-device policy
>    and deep parses the evidence for equivilance after the private key
>    is validated, carefully avoiding volatile evidence bytes.

Yes, Lukas was also pointing out that the existing driver reset/resume
handlers could signal "revalidated" as well if the PCI layer had no
opinion.

...but the point is that it is a menu of options, not a static policy.

> 3) User provides a BPF program and it runs on the evidence
> 
> 4) Standards bodies define a generic "same device check" algorithm for
>    the evidence and core kernel just does this for compatible devices
> 
> > The equivalent behavior to what is present in this SPDM proposal is
> > extend drivers/pci/tsm/evidence.c to add a netlink operation that tells
> > the kernel to cache the public-key and challenge the device regenerate a
> > valid signature. Then plumb all the recovery paths to call a new
> > 'struct pci_tsm_ops::revalidate()' operation in all the same places
> > where this patch set wants to reauthenticate. Later when something more
> > sophisticated than "challenge the device to create a signature" comes
> > along it can reuse those revalidate() hooks.
> 
> That's a nice simple starting point.

Appreciate it. Still want to close the loop with Lukas to make sure
everything he wants to do for native SPDM can fit in this scheme, but I
am feeling increasingly confident.

On Thu, 5 Mar 2026 11:49:27 -0800
dan.j.williams@intel.com wrote:

> Jason Gunthorpe wrote:
> > On Wed, Mar 04, 2026 at 08:17:24PM -0800, dan.j.williams@intel.com wrote:
> >   
> > > So I ended up dropping this bit of the proposal because there is no need
> > > for the kernel to be involved in any decision about the validity and
> > > sufficiency of device evidence. Userspace has everything it needs to
> > > make that initial determination. "Authenticated" simply means "evidence
> > > ready".  
> > 
> > Right, this caching was only for the automatic device recovery flow.
> > 
> > I think the kernel still probably needs to check the signed nonce
> > against the device's public key as part of the SPDM handshake, but it
> > doesn't need to do any validation of the public key.  
> 
> Yes, and I think this is a subtle detail that I was failing to grok /
> communicate previously. Of course the native SPDM implementation needs
> to be able to perform a challenge response to establish the session. All
> of the platform TSMs also internally carry out that protocol. The
> difference with platform TSMs being that the kernel only sees the
> resulting evidence.

I had a half written email on this but you two already covered much of it
and discussion is heading where I was going anyway :)

For native / CMA:

I agree that the kernel 'should' check the signature in the final
challenge/auth message so as to validate the whole flow was valid.
Fine to leave cert checking to userspace - that was earlier in
the flow anyway.  I'd also like it to do sanity checks on the cert
chain (for internal consistency and the few requirements PCI puts
on the leaf cert), some of which it needs to do to pull the public
key out of the leaf anyway. I think that's all cheap stuff to
detect failures early.

As far as I can tell, the signature check isn't strictly necessary
as userspace has all the info to do that signature check on the
transcript.  Bit of nasty parsing code but not particularly bad and
likely to be in tooling anyway for debug purposes. (I'm assuming that's
why there is a 'probably' above :)

We only _need_ the kernel to check the signature (in challenge/auth)
for the (future) recovery flow.

As Alastair's rust demonstrates though it's low cost in terms
of complexity to ensure internal consistency. I'm assuming
the various TSMs are doing similar?

Anyhow, all that really says is I'd like the internal consistency of
the SPDM session checking in now.  Leave checking we actually trust
the cert + measurements to user space (and all the stuff below
on recovery comes later).
> 
> So when / if the PCI/TSM evidence implementation grows kernel-internal
> revalidate support it will be growing something like pdev->tsm->pubkey
> that is installed / cached "after the fact" for platform TSMs. For the
> native SPDM driver, pdev->tsm->pubkey can be installed at 'struct
> pci_tsm_ops::connect()' time because it already has it parsed for its
> own internal purposes.

Agreed it'll be something along those lines.

> 
> > > Automatic device recovery into the TCB is a separate concern that needs
> > > to be prepared to handle more than just "is this device able to generate
> > > a fresh signature with the same cert chain that userspace saw before".
> > > Yes, that is a minimal requirement but not sufficient for many cases.
> > > For example cases that want to validate measurements, interface reports,
> > > or opt-out of recovery because SPDM session loss is fatal.  
> > 
> > Yeah, but it is a pretty good starting point :)
> >   
> > > Authenticate a device
> > > =====================
> > > Look in /sys/class/tsm to find a tsmN device which will be either an
> > > instance associated with native kernel PCI CMA/SPDM or a platform tsm
> > > like the one provided by AMD SEV-TIO, ARM CCA, Intel TDX, etc...
> > > 
> > > echo tsmN > /sys/bus/pci/devices/$device/tsm/connect
> > > 
> > > Once that succeeds the PCI/TSM evidence netlink interface is available
> > > to dump any signatures created during that session establishment.
> > > 
> > > After userspace is happy with that evidence it can bind a driver.
> > > 
> > > If running in a confidential VM where the TSM driver is capable of
> > > securing more than just an SPDM session the interface is:
> > > 
> > > echo tsmN > /sys/bus/pci/devices/$device/tsm/lock
> > > 
> > > Similar evidence can be collected, and when userspace is happy with it
> > > it can accept the device:
> > > 
> > > echo 1 > /sys/bus/pci/devices/$device/tsm/accept
> > > 
> > > ...and bind a driver.  
> > 
> > Makes sense to me, userspace can figure out what flow to use.
> >   
> > > Auto-recover device (future work)
> > > =================================
> > > By default, devices fall out of the TCB on recovery events for the TDISP
> > > case and need userspace to rerun the lock and accept flow. For the
> > > native SPDM CMA case the default is that the kernel continues to operate
> > > the device post recovery and only userspace polling could detect device
> > > replacement.  
> > 
> > Even with SPDM the kernel should know if the SPDM session has to be
> > restarted right? It could squirt out a netlink multicast message, or a
> > uevent on these events, so the polling is not baked into the
> > architecture?  
> 
> Right, "SPDM session lost" is a reasonable notification to put into the
> interface and "future work" bucket. The polling comment was with respect
> to the near term limitation of this minimally viable first step.
> 
> > > To go beyond those defaults the kernel needs userpsace to tell it how to
> > > re-validate the device. I think that can be as simple as a netlink
> > > message to store hashes of cert chains or measurements and then use
> > > those in a new challenge / response with the device with a kernel
> > > decided nonce.  
> > 
> > Yeah, I see several reasonable options:  
> 
> +1 to these.
> 
> > 1) Above, kernel is informed of hashes and does an exact content
> >    compare
> > 
> > 2) The driver operating the device has a built in same-device policy
> >    and deep parses the evidence for equivilance after the private key
> >    is validated, carefully avoiding volatile evidence bytes.  
> 
> Yes, Lukas was also pointing out that the existing driver reset/resume
> handlers could signal "revalidated" as well if the PCI layer had no
> opinion.
> 
> ...but the point is that it is a menu of options, not a static policy.
> 
> > 3) User provides a BPF program and it runs on the evidence
> > 
> > 4) Standards bodies define a generic "same device check" algorithm for
> >    the evidence and core kernel just does this for compatible devices
> >   
> > > The equivalent behavior to what is present in this SPDM proposal is
> > > extend drivers/pci/tsm/evidence.c to add a netlink operation that tells
> > > the kernel to cache the public-key and challenge the device regenerate a
> > > valid signature. Then plumb all the recovery paths to call a new
> > > 'struct pci_tsm_ops::revalidate()' operation in all the same places
> > > where this patch set wants to reauthenticate. Later when something more
> > > sophisticated than "challenge the device to create a signature" comes
> > > along it can reuse those revalidate() hooks.  
> > 
> > That's a nice simple starting point.  
> 
> Appreciate it. Still want to close the loop with Lukas to make sure
> everything he wants to do for native SPDM can fit in this scheme, but I
> am feeling increasingly confident.

So far all sounds good to me.

Jonathan

On Mon, Mar 09, 2026 at 11:39:41AM +0000, Jonathan Cameron wrote:

> Anyhow, all that really says is I'd like the internal consistency of
> the SPDM session checking in now.  Leave checking we actually trust
> the cert + measurements to user space (and all the stuff below
> on recovery comes later).

I think kernel doing internal consistency (non policy) checks is fine

We just need to be careful to construct things so it is compatible
with an external verifier. Even in this bare SPDM mode we still want
to hook it into external verification.

I don't know alot, but I understand this requires the nonce (?) to
come from userspace? I suppose the flow is the usual crypto something
like
 - Kernel negotiates a DH session/CSPRNG with the peer, generates
   symmetric keys from the CSPRNG 
 - Kernel forwards a nonce challenge and peer signs it, somehow mixing in
   CSPRNG data to bind to the DH session
 - Kernel checks the signature against the public key and confirms the
   CSPRNG and nonce are correct (only kernel can do this since the
   CSPRNG must not leak out of the kernel)
 - Kernel forwards the signature from the peer to userspace and
   userspace re-checks the signature against the public key and
   validates the nonce is the one it issued, and checks that the
   public key is acceptable. Ignores the CSPRNG data.
 - Presumably in a real TSM there will be a merkle tree signed by the
   TSM's platform key that binds together all the TVM measurements and
   the SPDM activity so the verifier can see a complete picture?

   ie that the verifier pushed nonce A authenticated SPDM session B
   which is part of PCI device C that is part of TVM D.

   Should kernel be extending TPM PCRs or something in this bare SPDM
   mode to provide something similar using the TPM to produce
   platform evidence?

Of course all of this should try to align with the way TSMs are
working so we have as uniform as possible uAPI for evidence transfer.
Though obviously a kernel SPDM has to be distinguisable from any other
TSM from a verifier POV.

Jason

On Mon, 9 Mar 2026 09:31:48 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Mon, Mar 09, 2026 at 11:39:41AM +0000, Jonathan Cameron wrote:
> 
> > Anyhow, all that really says is I'd like the internal consistency of
> > the SPDM session checking in now.  Leave checking we actually trust
> > the cert + measurements to user space (and all the stuff below
> > on recovery comes later).  
> 
> I think kernel doing internal consistency (non policy) checks is fine
> 
> We just need to be careful to construct things so it is compatible
> with an external verifier. Even in this bare SPDM mode we still want
> to hook it into external verification.
> 
> I don't know alot, but I understand this requires the nonce (?) to
> come from userspace? 

Going out of my area of expertise... So take the following with a pinch
of salt.

Yes to userspace provided nonce. My understanding is that can come
from the verifier that wants to ensure freshness.

I'm not sure exactly what our security model is in the native CMA case,
so what software we can trust on the host. I.e. does the DH session actually
need to be between the kernel and the peer?

> I suppose the flow is the usual crypto something
> like
>  - Kernel negotiates a DH session/CSPRNG with the peer, generates
>    symmetric keys from the CSPRNG 
>  - Kernel forwards a nonce challenge and peer signs it, somehow mixing in
>    CSPRNG data to bind to the DH session

We have a small amount of context (8 bytes) that we can put anything as
part of challenge/auth (alongside the nonce) It will part of the signed
response. Would that work for something from with the CSPRNG,
mixed so that you can't go from that context to the CSPRNG value?

>  - Kernel checks the signature against the public key and confirms the
>    CSPRNG and nonce are correct (only kernel can do this since the
>    CSPRNG must not leak out of the kernel)
>  - Kernel forwards the signature from the peer to userspace and
>    userspace re-checks the signature against the public key and
>    validates the nonce is the one it issued, and checks that the
>    public key is acceptable. Ignores the CSPRNG data.
>  - Presumably in a real TSM there will be a merkle tree signed by the
>    TSM's platform key that binds together all the TVM measurements and
>    the SPDM activity so the verifier can see a complete picture?
> 
>    ie that the verifier pushed nonce A authenticated SPDM session B
>    which is part of PCI device C that is part of TVM D.
> 
>    Should kernel be extending TPM PCRs or something in this bare SPDM
>    mode to provide something similar using the TPM to produce
>    platform evidence?
> 
> Of course all of this should try to align with the way TSMs are
> working so we have as uniform as possible uAPI for evidence transfer.
> Though obviously a kernel SPDM has to be distinguisable from any other
> TSM from a verifier POV.

Agreed. Very interesting to know what exactly is going in the TSM
SPDM exchanges as hopefully that will reflect best practice. If we
are really lucky they won't all do different things ;)

Jonathan



> 
> Jason

On Mon, Mar 09, 2026 at 03:33:39PM +0000, Jonathan Cameron wrote:

> I'm not sure exactly what our security model is in the native CMA case,
> so what software we can trust on the host. I.e. does the DH session actually
> need to be between the kernel and the peer?

Yes, absolutely a DH session is required in all cases, it is the only
way to generate a PCI encryption shared secret and exclude a MIM.

For native the verifer should be able to measure the running kernel
using the TPM, and then confirm the measured kernel and the peer have
established a MIM free PCIe encryption, and finally measure the peer
device.

For instance, imagine an enhanced version of "Network-Bound Disk
Encryption" where the storage key is not released unless the server
also validates PCI properties (physically encrypted with no MIM, right
devices, etc)

> > I suppose the flow is the usual crypto something
> > like
> >  - Kernel negotiates a DH session/CSPRNG with the peer, generates
> >    symmetric keys from the CSPRNG 
> >  - Kernel forwards a nonce challenge and peer signs it, somehow mixing in
> >    CSPRNG data to bind to the DH session
> 
> We have a small amount of context (8 bytes) that we can put anything as
> part of challenge/auth (alongside the nonce) It will part of the signed
> response. Would that work for something from with the CSPRNG,
> mixed so that you can't go from that context to the CSPRNG value?

I assume SPDM is doing this already somehow otherwise there is no way
to setup the PCI encryption keys. The fundamental purpose of the
signature is to exclude a MIM by signing something that proves there
is no MIM, and that is usually a value that both sides independently
pull out of the CSPRNG. If they derive the same value then they have
the same CSPRNG and DH tells us nobody else can have it. But there are
other approaches too..

> > Of course all of this should try to align with the way TSMs are
> > working so we have as uniform as possible uAPI for evidence transfer.
> > Though obviously a kernel SPDM has to be distinguisable from any other
> > TSM from a verifier POV.
> 
> Agreed. Very interesting to know what exactly is going in the TSM
> SPDM exchanges as hopefully that will reflect best practice. If we
> are really lucky they won't all do different things ;)

Yeah, and I don't really know the details, just have some general idea
how attestation and PCI link encryption should work in broad strokes.

But I know people who do, so if we can get a series that clearly lays
out the proposed kernel flow I can possibly get someone to compare
it..

The baseline I expect is a merkle tree signed by the root of trust
(TPM or platform TSM) that encompases everything down to the required
bits of the SPDM negotiation to prove no MIM.

Jason

On Mon, 9 Mar 2026 12:59:09 -0300
Jason Gunthorpe <jgg@nvidia.com> wrote:

> On Mon, Mar 09, 2026 at 03:33:39PM +0000, Jonathan Cameron wrote:
> 
> > I'm not sure exactly what our security model is in the native CMA case,
> > so what software we can trust on the host. I.e. does the DH session actually
> > need to be between the kernel and the peer?  
> 
> Yes, absolutely a DH session is required in all cases, it is the only
> way to generate a PCI encryption shared secret and exclude a MIM.

Ah. I was missing what you wanted with the DH part. For some reason wasn't
thinking about IDE (maybe because this patch set doesn't get you there for
native). Though as I understand it some of the native usecases for CMA aren't
using link encryption (different security model from CoCo).

Yes, if you want to avoid MIM you need to bring up IDE etc - the basic fact
that both ends can still talk to each other after enabling it given they have
to have the same keys and those went over the secure channel, is part of the
security around that. I think you can attest before that point and rely on
the link 'failing' if there was a man in the middle. The verifier would
want the evidence IDE was up before giving you any secrets.

Whether anyone actually implements root ports via standard DOE flows or
everyone does this a custom way at the host is an open question.
There are various mix and match situations where the Coco / TSM flows
mean we have an encrypted channel, but we are doing our own native
attestation (to a different DOE, say on a VF).  Anyhow, others on this thread
have more info (I think) on the corner cases of how this is going to be
used than I do.

The secure channel establishment and key exchange comes later in the SPDM
flow than this patch set currently covers. This bit just gets you to the
point where you know you are ultimately talking to right device - you don't
know there isn't a MIM at this point.

Next up is KEY_EXCHANGE / KEY_EXCHANGE_RSP / FINISH / FINISH_RSP that will
exchange the public ephemeral keys and ultimately get us a secure channel.
Then we then switch to secured-CMA which is the PCIe spec and is basically the
format for wrapping up the session IDs etc + the encrypted channel.
Lukas' github has the next few bits required, but not sure he's all the
way there yet?

That then gets used for key exchange messages related to IDE via the PCI
spec defined IDE_KM protocol. (which is fairly simple compared to the other
steps - only about 8 pages :)).

So we may need to get a bit further before we can do the attestation
flow that would be equivalent to what CoCo needs.  I'm thinking
we may need one more set of measurements to verify both ends think
IDE is up.

For now the host will know it didn't bring up IDE.

> 
> For native the verifer should be able to measure the running kernel
> using the TPM, and then confirm the measured kernel and the peer have
> established a MIM free PCIe encryption, and finally measure the peer
> device.
> 
> For instance, imagine an enhanced version of "Network-Bound Disk
> Encryption" where the storage key is not released unless the server
> also validates PCI properties (physically encrypted with no MIM, right
> devices, etc)
> 
> > > I suppose the flow is the usual crypto something
> > > like
> > >  - Kernel negotiates a DH session/CSPRNG with the peer, generates
> > >    symmetric keys from the CSPRNG 
> > >  - Kernel forwards a nonce challenge and peer signs it, somehow mixing in
> > >    CSPRNG data to bind to the DH session  
> > 
> > We have a small amount of context (8 bytes) that we can put anything as
> > part of challenge/auth (alongside the nonce) It will part of the signed
> > response. Would that work for something from with the CSPRNG,
> > mixed so that you can't go from that context to the CSPRNG value?  
> 
> I assume SPDM is doing this already somehow otherwise there is no way
> to setup the PCI encryption keys. The fundamental purpose of the
> signature is to exclude a MIM by signing something that proves there
> is no MIM, and that is usually a value that both sides independently
> pull out of the CSPRNG. If they derive the same value then they have
> the same CSPRNG and DH tells us nobody else can have it. But there are
> other approaches too..

For SPDM it's this or pre shared key stuff which requires some out of
band way path. So probably ignore that.

> 
> > > Of course all of this should try to align with the way TSMs are
> > > working so we have as uniform as possible uAPI for evidence transfer.
> > > Though obviously a kernel SPDM has to be distinguisable from any other
> > > TSM from a verifier POV.  
> > 
> > Agreed. Very interesting to know what exactly is going in the TSM
> > SPDM exchanges as hopefully that will reflect best practice. If we
> > are really lucky they won't all do different things ;)  
> 
> Yeah, and I don't really know the details, just have some general idea
> how attestation and PCI link encryption should work in broad strokes.
> 
> But I know people who do, so if we can get a series that clearly lays
> out the proposed kernel flow I can possibly get someone to compare
> it..
> 
> The baseline I expect is a merkle tree signed by the root of trust
> (TPM or platform TSM) that encompases everything down to the required
> bits of the SPDM negotiation to prove no MIM.

Agreed, that's my basic undestanding as well and likewise, can get
some appropriate folk to check it out once we have the full thing described.

Jonathan

> 
> Jason
>

On Mon, Mar 09, 2026 at 06:00:54PM +0000, Jonathan Cameron wrote:
> On Mon, 9 Mar 2026 12:59:09 -0300
> Jason Gunthorpe <jgg@nvidia.com> wrote:
> 
> > On Mon, Mar 09, 2026 at 03:33:39PM +0000, Jonathan Cameron wrote:
> > 
> > > I'm not sure exactly what our security model is in the native CMA case,
> > > so what software we can trust on the host. I.e. does the DH session actually
> > > need to be between the kernel and the peer?  
> > 
> > Yes, absolutely a DH session is required in all cases, it is the only
> > way to generate a PCI encryption shared secret and exclude a MIM.
> 
> Ah. I was missing what you wanted with the DH part. For some reason wasn't
> thinking about IDE (maybe because this patch set doesn't get you there for
> native). Though as I understand it some of the native usecases for CMA aren't
> using link encryption (different security model from CoCo).

Yeah, there are models where you could collect evidence and not have
any IDE setup where you have greater trust in physical security.

> Yes, if you want to avoid MIM you need to bring up IDE etc - the basic fact
> that both ends can still talk to each other after enabling it given they have
> to have the same keys and those went over the secure channel, is part of the
> security around that. 

No.. With DH systems something can sit in the middle and
encrypt/decrypt and you can't detect that unless you sign something
derived from the DH the other side can validate.

> Whether anyone actually implements root ports via standard DOE flows or
> everyone does this a custom way at the host is an open question.

I'm expecting Linux will be able to setup Link IDE, either through a
platform TSM as you say, or through someone plugging in the IDE
registers into some Linux drivers.. I certainly don't want to close
that door by bad uAPI design.

> The secure channel establishment and key exchange comes later in the SPDM
> flow than this patch set currently covers. This bit just gets you to the
> point where you know you are ultimately talking to right device - you don't
> know there isn't a MIM at this point.

Hmm, like I said I don't really know the flow, but something has to
bind the DH into the evidence for it to be useful, if that comes after
(seems backwards, but OK) then as long as the evidence reporting and
controlling uAPI is happy with all these different flows OK..

Jason

Jason Gunthorpe wrote:
[..]
> > Whether anyone actually implements root ports via standard DOE flows or
> > everyone does this a custom way at the host is an open question.
> 
> I'm expecting Linux will be able to setup Link IDE, either through a
> platform TSM as you say, or through someone plugging in the IDE
> registers into some Linux drivers.. I certainly don't want to close
> that door by bad uAPI design.

Right now there is no extra uAPI for IDE. It is an implicit detail of
the given TSM whether the "connect" operation additionally establishes
IDE. The result of whether or not "connect" established
selective-stream-IDE with the device is conveyed in the arrival of
"stream" links in sysfs, see:

Documentation/ABI/testing/sysfs-devices-pci-host-bridge

You also asked:

> Yeah, and I don't really know the details, just have some general idea
> how attestation and PCI link encryption should work in broad strokes.
> 
> But I know people who do, so if we can get a series that clearly lays
> out the proposed kernel flow I can possibly get someone to compare
> it..

tl;dr: can you point them at http://lore.kernel.org/20260303000207.1836586-1-dan.j.williams@intel.com

A couple notes that the host kernel is unable to establish IDE without a
platform TSM on all but Intel platforms (that I know of). At a minimum,
this is why I think native SPDM should behave as a TSM driver. Platform
TSM involvement for IDE is the predominant architecture in the
ecosystem.

As for link encryption and attestation it is all rooted in the launch
attestation of the VM. Once you trust that the TSM that claims to be
present is valid then you trust all of that TSMs ABIs to enforce
confidentiality and integrity.

Now, a TSM is free to decide, "I do not need PCI link encryption because
I have apriori knowledge that $device has a connection to the system
that meets confidentiality + integrity expectations". So link encryption
is present for discrete devices, but maybe not integrated devices.

Assuming VM launch attesation gets you trust in the guest TSM driver
responses, then the attestation flow to the kernel is mostly just
marshaling blobs and digests:

1/ Host collects a fresh copy of device measurements with a guest
provided nonce (response emitted by PCI/TSM netlink, nonce received
via guest-to-host communication, see AF_VSOCK comment in 2/).

2/ Host marshals cert chain, measurements (signed transcript with nonce
from 1/), and interface report blob to guest via an untrusted channel. I
am currently thinking just use a common transport like AF_VSOCK to get
those blobs into the guest and not have each implementation reinvent
that blob transfer wheel.

3/ Guest needs to validate that blobs are indeed the ones the TSM
expects. Each TSM has a private message protocol to request digests of
the blob contents for this purpose.

At no point is the guest offered explicit PCI link encryption details,
nor the host for that matter. I think some TSMs might include the key
exchange steps in the SPDM transcript. However, that happens within an
SPDM secure session, so host can not otherwise observe it.  SPDM does
support mutual authentication so the device could in theory challenge
whether it is talking to a device-approved TSM.

The open question I generated typing this up, is that if a common
transport is used to get the blobs into guest userspace, that userspace
still needs to push the "interface report" blob into the guest kernel.
Kernel needs that to determine how to map private vs shared MMIO. I
still think I prefer that to each implementation having a set of
implementation specific message passing ioctls() to do the same.

On Mon, Feb 23, 2026 at 11:11:23AM -0800, dan.j.williams@intel.com wrote:
> Jonathan Cameron wrote:
> [..] 
> > From a simple case of 'what is here' in this set, the only bit I'm seeing
> > change in order to implement what I think you and Jason are describing is we
> > don't bother checking the cert chain in kernel for the first time: We
> > provide that to userspace to decide if it's good. If I understand
> > correctly, this will be at the end of the full sequence once we've pushed
> > through a nonce and gotten signatures + measurements.  Same as checking a
> > TSM provided transcript. That was sort of happening anyway if we consider
> > the .cma keyring as just providing a short cut filter if we didn't trust
> > the device provided root cert.
> > User space got the transcripts before it had to make any decision on
> > binding and could do anything it liked with them.
> 
> Exactly, the kernel checking the cert is not sufficient to establish
> trust in the device interface (Link + MMIO). If userspace is making a
> driver-bind or TDISP accept decision, it needs
> certs+measurements+interface-report and does not benefit from the kernel
> also validating the certificate.

Right, and from that position you have to ask *why* would the kernel
ever check the certs, what use case is that supporting, and I can't
come up with any beyond some kernel-internal simple verifier. So why
do we have a cma keyring at all?

I'm willing to be convinced there is some compelling embedded reason
why putting the verifier in the kernel instead of userspcae saves a
meaningful amount of flash - but I don't think we should start there
on the kernel side. First kernel steps should be to enable the
userspace verifier flow, which serves all use cases and offers the
highest policy flexibility.

Resume/RAS is handled by a much stronger same device check, not a weaker
kernel verifier with a root of trust in a keyring.

If somebody eventually wants a weaker check on resume then come with
that explanation and justification and lets talk about it later. I
would probably offer an eBPF policy hook not a CMA keyring though...

> > For that caching the public key bit, I'm not clear on whether you intend
> > to do that from kernel side (which I think I'd prefer) or have user space
> > squirt that key back in again?  If we are doing it in kernel we can
> > at least always verify the transcript is self consistent and refuse to
> > give anything to user space if it's not consistent (other than debug material).
> > By self consistent I mean we verify the signature against the device provided
> > cert (might as well verify whole chain as that's trivial given we have to partly
> > parse them anyway to find the cert).  I don't think it maters hugely if
> > we do this in kernel beyond advantage of removing a few foot guns and
> > simplifying the userpace interface to "I'm fine with the provided transcript
> > for use when I'm not here next time" write. Disadvantage is we use the
> > cert parsing code (which is there anyway) and parse it all twice - once
> > in kernel and probably again in userspace or at some remote verifier.
> 
> Right, the proposal is cache the public-key from pci_tsm_ops::connect()
> and at least require that the resulting transcript from that session
> establishment is properly self-signed. No point in continuing with a TSM
> implementation that is not self-consistent.

I don't have a strong feeling either way, but agree having the kernel
do it automatically and magically seems overall better if it is
possible.

What I want to achieve is a very strong robust 'same device check'
such that if the same device check passes then the userspace verifier
would accept the device again as nothing it could be sensitive to
would change.

As I said in the other email I expect the private keys to be unique to
the physical device so checking the leaf certificates is most of the
way to a same device check. You then need to confirm the FW
configuration of the device is identical.
 
> > Measurement verification (in kernel) is potentially a trickier bit of ABI
> > design as the space of what might be in there and what matters for a given
> > device is complex to say the least.  Only a small part of that is spec
> > defined.

Yes, I suggested we may have the device driver contribute this. From a
kernel perspective we can set out what 'same device check' means and
the drivers have to implement this by processing thier own device
specific attestation.

It is not the same as trying to do "measurement verificaiton" where
you may have a broad policy of what versions and configurations are
acceptable. Here we want simple "measurement has not changed", which I
think is reasonable to do in the kernel.

I gather these attestation reports are complex to parse so it would
make sense to do all that in rust...

> > I can see there may be some use cases where we relax things beyond this
> > (potentially including .cma keyring and root cert only)
> 
> So I expect there will be an extended tail of problems to solve from
> same device and same measurements checks, to full recovery into the TCB.
> A .cma keyring may be a part of that eventually, but the "as simple as
> possible, but no simpler" starting point is userspace device policy
> wrapped around self-signed evidence.

I'm also willing to entertain a cma keyring, but only with a strong
justification and fitting into this overall security model after we
establish the initial basic flows in their most secure versions.

> If the device interface is adversarial, mere trust in the SPDM session
> is insufficient to protect against the type of attacks that re-checking
> the certificate only after reset/resume is meant to mitigate.

Right, if you want to exclude physical attacks checking certificates
only is clearly not sufficient.

Jason

Jason Gunthorpe wrote:
> On Thu, Feb 19, 2026 at 04:07:58PM +0100, Lukas Wunner wrote:
> > On Thu, Feb 19, 2026 at 10:31:29AM -0400, Jason Gunthorpe wrote:
> > > On Thu, Feb 19, 2026 at 03:15:34PM +0100, Lukas Wunner wrote:
> > > > The way this works in my series (and I presume Alistair's) is that
> > > > trusted root certificates for devices need to be added to the .cma
> > > > keyring.
> > > > 
> > > > This can be done from user space using keyctl(1) or some other utility
> > > > that can talk to the kernel's existing keyctl ABI.
> > > 
> > > I really don't like this from a verification perspective. We don't
> > > want the kernel checking signatures, that is the verifier's job.
> > 
> > On resume from system sleep, the device is put into D0 already in the
> > ->resume_noirq() phase and drivers are free to access it already at
> > that point.  However a verifier in user space cannot be queried
> > at that point because user space is still frozen.
> > 
> > Likewise after recovery from DPC or AER, the device has been reset
> > and needs to be reauthenticated, yet user space may be unavailable
> > because the device that has been reset may contain the root partition
> > or may be the NIC that you need to query your remote attestation service.
> > 
> > There is no way around some form of in-kernel device authentication
> > to accommodate such use cases.
> 
> I'm arguing there are two very different steps here that must be kept
> separate. Verification is done when the device is first seen and the
> kernel is told it is OK to use the device.
> 
> A same-device check is performed if an already verified and accepted
> device resumes or RAS's in some way.
> 
> same-device does not mean run a kernel verification against the kernel
> keyring, as a second verification could be tricked into accepting
> something that has changed and defeat the userspace verifier.
> 
> Instead the implementation should capture information when the device
> is accepted by the verifier and on resume/RAS it should compare the
> device against that captured information and determine if it is still
> the same device.
> 
> The key north star must be that the userspace verifier alone decides
> if the device is acceptable and if the kernel is configured to
> auto-re-accept the device later on RAS/resume it must not permit a
> device that is different from what userspace approved. In other words
> it is not a verification on resume, it is just a kernel side
> confirmation the device hasn't been changed.
> 
> Hence no keyring should be involved in resume.

I am also struggling to see a role for the .cma keyring as long as the
kernel eventually has a method to cache cert-chain, measurements, and
for TDISP, interface report digests. Support for a recovery flow is not
the first dragon to slay though as just establishing device trust in the
first instance without RAS concerns is a significant amount of work.

Linux should not over index on native bare-metal CMA because that
mechanism only tells you that the SPDM session with device firmware
(DSM) is authenticated, it does nothing to ensure that the kernel's view
of the device's MMIO is and remains associated with that DSM. Better
than nothing, yes, but it certainly assumes a less sophisticated threat
model than TDISP.

So the current 'authenticated' PCI sysfs attribute can simply indicate
"SPDM collateral (cert chain + measurements) available", and leave all
the decisions about what do with that collateral to userspace. For cases
where the full lock + accept TDISP flow is not available the only policy
knob that userspace has is to decline to attach a driver.

Once we have that userspace can optionally tell the kernel to cache
digests for automatic re-accept / keep driver bound, or userspace can
plan to do another round trip with the verifier for recovery if the
device bounces out of the TCB.

My current thought is take and adapt the netlink interface to retrieve
cert chains, change the certificate slot for the authentication attempt,
and retrieve device measurements. None of that requires the x509 parser.
With that in place native CMA SPDM can be modeled as just another TSM
driver that only addresses a subset of the TDISP threat model.

There are 2 flows depending on whether the TSM driver suports the
comprehensive security of the "lock+accept" model or not:

---

# $tsmN is a class device registered by one of amd-tio, intel-tdx,
# arm-cca, or when this spdm library is available a kernel-pci-cma TSM
# driver

# The "lock+accept" model is not available for any of the current tsm
# drivers on bare metal, only the "connect" flow. The connect flow gets
# you an SPDM secure session at a minimum and optionally IDE as well. It
# is a less comprehensive security model than TDISP
echo $tsmN > /sys/bus/pci/devices/$pci_dev/tsm/connect

# Alternatively, when a TDISP interface is assigned, the TSM driver
# publishes "lock+accept" attributes. This provides the comprehensive
# security model that closes "DSM is and remains associated to device
# MMIO" TOCTOU problem.
echo $tsmN > /sys/bus/pci/devices/$pci_dev/tsm/lock

# In either of the above cases the
# /sys/bus/pci/devices/$pci_dev/authenticated attribute toggles to 1 and
# userspace is able to use PCI netlink to gather evidence with nonces
...collect (with netlink) / validate evidence...

# When verifier is satisfied bind the driver, or in the Confidential
# Computing / TDISP case, first "accept" the device so that it is
# allowed to access private memory
echo 1 > /sys/bus/pci/devices/$pci_dev/tsm/accept
echo $pci_dev > /sys/bus/pci/drivers/$driver/bind

---

Jason Gunthorpe wrote:
> On Wed, Feb 18, 2026 at 03:40:10PM -0800, dan.j.williams@intel.com wrote:
> 
> > So one proposal to get the x509 pre-work upstream is to extend the TSM
> > core (drivers/pci/tsm.c) to export the certificates in sysfs, and update
> > the existing "authenticated" attribute to reflect the result of cert
> > chain validation.
> 
> Why do we want the validate the cert chain in the kernel? That sounds
> like something the verifier should do?

This is more for the CMA case where Lukas was imagining automatic
revalidation of device certificates coming out of resume before
userspace is present. If someone wanted to use a TSM for device-auth +
link encryption outside of TDISP and Confidential VMs, then it could use
the same mechanism.

However, error handling / automatic reset recovery is out of scope for
the first phase of the TDISP enabling. Also all the early TDISP use
cases seem focused on datacenter where there is no need for the VMM to
authenticate the device. I am ok to defer the "authenticate while
userspace is unavailable" scheme to keep this simple.

> And not sure we should be dumping any certs in sysfs if the plan for
> the other stuff is netlink, it should be consistent I think.

Lukas was only putting the dynamic / transactional pieces in netlink.
Specifically device signature events (multicast) and device measurement
collection with a nonce.

The static cert chain blobs can certainly also be in netlink... but no
real driving need like there was for the other flows. I am also
encouraged by Lukas's work to handle large blobs over netlink [1], but
no real need to add that as a dependency to this simple mission of "just
enough of a real user to land the crypto prep patches".

[1]: https://github.com/l1k/linux/commit/af9b939fc30b

On Wed, Feb 18, 2026 at 09:05:28PM -0800, dan.j.williams@intel.com wrote:
> Jason Gunthorpe wrote:
> > On Wed, Feb 18, 2026 at 03:40:10PM -0800, dan.j.williams@intel.com wrote:
> > 
> > > So one proposal to get the x509 pre-work upstream is to extend the TSM
> > > core (drivers/pci/tsm.c) to export the certificates in sysfs, and update
> > > the existing "authenticated" attribute to reflect the result of cert
> > > chain validation.
> > 
> > Why do we want the validate the cert chain in the kernel? That sounds
> > like something the verifier should do?
> 
> This is more for the CMA case where Lukas was imagining automatic
> revalidation of device certificates coming out of resume before
> userspace is present. If someone wanted to use a TSM for device-auth +
> link encryption outside of TDISP and Confidential VMs, then it could use
> the same mechanism.

I think we should have one flow for this based on what we talked about
for TDSIP.

We are thinking about many interesting models, and some of them
include running an external verifier on this no-VM case well. Kernel
auto acceptance is not desirable for the same reasons it is not
desirable in a TVM.

If we do some automatic re-accept for RAS/resume it should be strongly
tied to some target pre-set by the userspace acceptance process - ie
"the device must present exactly this specific cert chain and nothing
else", and probably more too since we may want to exclude swapping out
device FW versions or similar.

Not sure how that fits into an sysfs file.

> > And not sure we should be dumping any certs in sysfs if the plan for
> > the other stuff is netlink, it should be consistent I think.
> 
> Lukas was only putting the dynamic / transactional pieces in netlink.
> Specifically device signature events (multicast) and device measurement
> collection with a nonce.
> 
> The static cert chain blobs can certainly also be in netlink... but no
> real driving need like there was for the other flows. I am also
> encouraged by Lukas's work to handle large blobs over netlink [1], but
> no real need to add that as a dependency to this simple mission of "just
> enough of a real user to land the crypto prep patches".

It could, but also it seems like it just makes it more complicated to
force the verifying agent to use a combination of netlink and sysfs.

Jason

alistair23@ wrote:
> From: Alistair Francis <alistair.francis@wdc.com>

Hi Alistair, quite a bit to digest here and details to dig into. Before
getting into that, I will say that at a broad strokes level, no immune
response to the core proposal of depending on a Rust SPDM library and
forgoing a C SPDM library.

Most of that allergy relief comes from how this organizes the C to
Rust interactions. The core SPDM implementation calls out to C for the
presentation layer (Netlink) or is invoked by sysfs. That makes it
amenable for sharing those presentation mechanics.

Specifically, my primary concern is integration and refactoring
opportunities with the PCI TSM implementation [1]. The PCI TSM case
should use the same uABI transport for requesting + conveying device
certificate chain, SPDM transcript, and device measurements as PCI CMA.
Note that in the TSM case the SPDM implementation is in platform
firmware and will bypass this library. The TSM SPDM session is mutually
exclusive with the CMA SPDM session.

[1]: http://lore.kernel.org/69339e215b09f_1e0210057@dwillia2-mobl4.notmuch

> Security Protocols and Data Models (SPDM) [1] is used for authentication,
> attestation and key exchange. SPDM is generally used over a range of
> transports, such as PCIe, MCTP/SMBus/I3C, ATA, SCSI, NVMe or TCP.
> 
> From the kernels perspective SPDM is used to authenticate and attest devices.
> In this threat model a device is considered untrusted until it can be verified
> by the kernel and userspace using SPDM. As such SPDM data is untrusted data
> that can be mallicious.
> 
> The SPDM specification is also complex, with the 1.2.1 spec being almost 200
> pages and the 1.3.0 spec being almost 250 pages long.
> 
> As such we have the kernel parsing untrusted responses from a complex
> specification, which sounds like a possible exploit vector. This is the type
> of place where Rust excels!
> 
> This series implements a SPDM requester in Rust.
> 
> This is very similar to Lukas' implementation [2]. This series includes patches
> and files from Lukas' C SPDM implementation, which isn't in mainline.
> 
> This is a standalone series and doesn't depend on Lukas' implementation.

So, I *am* allergic to how this series references Lukas' work by
pointing to random points in his personal git tree. I trust that was
done for RFC purposes, but it would have helped to call that out in the
changelog and set expectations about the ideal path to coordinate with
that work.

> To help with maintaining compatibility it's designed in a way to match Lukas'
> design and the state struct stores the same information, although in a Rust
> struct instead of the original C one.
> 
> This series exposes the data to userspace via netlink, with a single sysfs
> atrribute to allow reauthentication.
> 
> All of the patches are included in the RFC, as it depends on some patches
> that aren't upstream yet.
> 
> Now that Rust is no longer experimental I have picked this back up. If the
> community is generally on board with a Rust implementation I can work on
> sending a non-RFC version and push towards getting that merged.

As long as this stays explicitly designed to minimize exposure to
"refactor across language boundary" events (as initially seems to be the
case), then it seems workable.

> The entire tree can be seen here: https://github.com/alistair23/linux/tree/alistair/spdm-rust
> 
> I'm testing the netlink data by running the following
> 
> ```shell
> cargo run -- --qemu-server response
> 
> qemu-system-x86_64 \
>   -nic none \
>   -object rng-random,filename=/dev/urandom,id=rng0 \
>   -device virtio-rng-pci,rng=rng0 \
>   -drive file=deploy/images/qemux86-64/core-image-pcie-qemux86-64.rootfs.ext4,if=virtio,format=raw \
>   -usb -device usb-tablet -usb -device usb-kbd \
>   -cpu Skylake-Client \
>   -machine q35,i8042=off \
>   -smp 4 -m 2G \
>   -drive file=blknvme,if=none,id=mynvme,format=raw \
>   -device nvme,drive=mynvme,serial=deadbeef,spdm_port=2323,spdm_trans=doe \
>   -snapshot \
>   -serial mon:stdio -serial null -nographic \
>   -kernel deploy/images/qemux86-64/bzImage \
>   -append 'root=/dev/vda rw  console=ttyS0 console=ttyS1 oprofile.timer=1 tsc=reliable no_timer_check rcupdate.rcu_expedited=1 swiotlb=0 '
> 
> spdm_utils identify &
> sleep 1
> echo re > /sys/devices/pci0000:00/0000:00:03.0/authenticated

So this is where it will collide with TSM that also emits an
authenticated attribute. See Documentation/ABI/testing/sysfs-bus-pci.

The rough plan Lukas and I worked out is that switching between TSM and
CMA based authentication would use sysfs visibility to coordinate. I.e.
TSM to CMA conversion hides the TSM "authenticated" attribute and
unhides the CMA attribute of the same name.

The most significant unsolved point of contention between TSM and CMA is
the policy on when authentication is mandated and the driver probe
policy. The proposed model for enforcing device security for
Confidential Computing is make it completely amenable to userspace
policy. Draft details here [2] to be refreshed "soon" when I send out
the next version of that.

[2]: http://lore.kernel.org/20250827035259.1356758-6-dan.j.williams@intel.com

To be clear I am ok if there is an incremental option to have auto_cma
and/or auto_tsm that arranges for authentication or link encryption to
happen without asking. I take issue with auto_cma being the only hard
coded option.

On Thu, Feb 12, 2026 at 3:56 PM <dan.j.williams@intel.com> wrote:
>
> alistair23@ wrote:
> > From: Alistair Francis <alistair.francis@wdc.com>
>
> Hi Alistair, quite a bit to digest here and details to dig into. Before
> getting into that, I will say that at a broad strokes level, no immune
> response to the core proposal of depending on a Rust SPDM library and
> forgoing a C SPDM library.
>
> Most of that allergy relief comes from how this organizes the C to
> Rust interactions. The core SPDM implementation calls out to C for the
> presentation layer (Netlink) or is invoked by sysfs. That makes it
> amenable for sharing those presentation mechanics.

Great! That was my goal.

Also, with netlink some of the C code is autogenerated, so a Rust
version would be tricky to do well.

>
> Specifically, my primary concern is integration and refactoring
> opportunities with the PCI TSM implementation [1]. The PCI TSM case
> should use the same uABI transport for requesting + conveying device
> certificate chain, SPDM transcript, and device measurements as PCI CMA.

I do think broadly that they can use the same uABI. I'm sure there
will be refactoring required though.

> Note that in the TSM case the SPDM implementation is in platform
> firmware and will bypass this library. The TSM SPDM session is mutually
> exclusive with the CMA SPDM session.

As long as we can get the details from the platform firmware (which I
assume is possible) then we can present them to userspace via the same
netlink ABI.

>
> [1]: http://lore.kernel.org/69339e215b09f_1e0210057@dwillia2-mobl4.notmuch
>
> > Security Protocols and Data Models (SPDM) [1] is used for authentication,
> > attestation and key exchange. SPDM is generally used over a range of
> > transports, such as PCIe, MCTP/SMBus/I3C, ATA, SCSI, NVMe or TCP.
> >
> > From the kernels perspective SPDM is used to authenticate and attest devices.
> > In this threat model a device is considered untrusted until it can be verified
> > by the kernel and userspace using SPDM. As such SPDM data is untrusted data
> > that can be mallicious.
> >
> > The SPDM specification is also complex, with the 1.2.1 spec being almost 200
> > pages and the 1.3.0 spec being almost 250 pages long.
> >
> > As such we have the kernel parsing untrusted responses from a complex
> > specification, which sounds like a possible exploit vector. This is the type
> > of place where Rust excels!
> >
> > This series implements a SPDM requester in Rust.
> >
> > This is very similar to Lukas' implementation [2]. This series includes patches
> > and files from Lukas' C SPDM implementation, which isn't in mainline.
> >
> > This is a standalone series and doesn't depend on Lukas' implementation.
>
> So, I *am* allergic to how this series references Lukas' work by
> pointing to random points in his personal git tree. I trust that was
> done for RFC purposes, but it would have helped to call that out in the
> changelog and set expectations about the ideal path to coordinate with
> that work.

I was trying to convey that a lot of this work was done by Lukas, I
didn't want to appear to be claiming otherwise or stepping on toes,
hence the links to his git tree.

As for an ideal path forward, what I think would be really useful is
if Lukas' prep patches get merged. Lukas sent them in his original
series and they have been reviewed there. I have picked them up here
to help with testing, but they could go upstream today and set the
ground work for either a C or Rust implementation.

That would reduce the size of any future series as well.

From there it would be worth thinking about a C or Rust implementation
and maybe just focus on one and work towards that.

>
> > To help with maintaining compatibility it's designed in a way to match Lukas'
> > design and the state struct stores the same information, although in a Rust
> > struct instead of the original C one.
> >
> > This series exposes the data to userspace via netlink, with a single sysfs
> > atrribute to allow reauthentication.
> >
> > All of the patches are included in the RFC, as it depends on some patches
> > that aren't upstream yet.
> >
> > Now that Rust is no longer experimental I have picked this back up. If the
> > community is generally on board with a Rust implementation I can work on
> > sending a non-RFC version and push towards getting that merged.
>
> As long as this stays explicitly designed to minimize exposure to
> "refactor across language boundary" events (as initially seems to be the
> case), then it seems workable.
>
> > The entire tree can be seen here: https://github.com/alistair23/linux/tree/alistair/spdm-rust
> >
> > I'm testing the netlink data by running the following
> >
> > ```shell
> > cargo run -- --qemu-server response
> >
> > qemu-system-x86_64 \
> >   -nic none \
> >   -object rng-random,filename=/dev/urandom,id=rng0 \
> >   -device virtio-rng-pci,rng=rng0 \
> >   -drive file=deploy/images/qemux86-64/core-image-pcie-qemux86-64.rootfs.ext4,if=virtio,format=raw \
> >   -usb -device usb-tablet -usb -device usb-kbd \
> >   -cpu Skylake-Client \
> >   -machine q35,i8042=off \
> >   -smp 4 -m 2G \
> >   -drive file=blknvme,if=none,id=mynvme,format=raw \
> >   -device nvme,drive=mynvme,serial=deadbeef,spdm_port=2323,spdm_trans=doe \
> >   -snapshot \
> >   -serial mon:stdio -serial null -nographic \
> >   -kernel deploy/images/qemux86-64/bzImage \
> >   -append 'root=/dev/vda rw  console=ttyS0 console=ttyS1 oprofile.timer=1 tsc=reliable no_timer_check rcupdate.rcu_expedited=1 swiotlb=0 '
> >
> > spdm_utils identify &
> > sleep 1
> > echo re > /sys/devices/pci0000:00/0000:00:03.0/authenticated
>
> So this is where it will collide with TSM that also emits an
> authenticated attribute. See Documentation/ABI/testing/sysfs-bus-pci.
>
> The rough plan Lukas and I worked out is that switching between TSM and
> CMA based authentication would use sysfs visibility to coordinate. I.e.
> TSM to CMA conversion hides the TSM "authenticated" attribute and
> unhides the CMA attribute of the same name.

That sounds fine to me

>
> The most significant unsolved point of contention between TSM and CMA is
> the policy on when authentication is mandated and the driver probe
> policy. The proposed model for enforcing device security for
> Confidential Computing is make it completely amenable to userspace
> policy. Draft details here [2] to be refreshed "soon" when I send out
> the next version of that.
>
> [2]: http://lore.kernel.org/20250827035259.1356758-6-dan.j.williams@intel.com
>
> To be clear I am ok if there is an incremental option to have auto_cma
> and/or auto_tsm that arranges for authentication or link encryption to
> happen without asking. I take issue with auto_cma being the only hard
> coded option.

Ok, so we would need a way for users to select TSM or CMA and specify
policy information?

Alistair