All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: dan.j.williams@intel.com, Alistair Francis <alistair23@gmail.com>,
	bhelgaas@google.com, rust-for-linux@vger.kernel.org,
	akpm@linux-foundation.org, linux-pci@vger.kernel.org,
	Jonathan.Cameron@huawei.com, linux-cxl@vger.kernel.org,
	linux-kernel@vger.kernel.org, alex.gaynor@gmail.com,
	benno.lossin@proton.me, boqun.feng@gmail.com,
	a.hindborg@kernel.org, gary@garyguo.net,
	bjorn3_gh@protonmail.com, tmgross@umich.edu, ojeda@kernel.org,
	wilfred.mallawa@wdc.com, aliceryhl@google.com,
	Alistair Francis <alistair.francis@wdc.com>,
	aneesh.kumar@kernel.org, yilun.xu@linux.intel.com, aik@amd.com,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Thomas Fossati <thomas.fossati@linaro.org>
Subject: Re: [RFC v3 00/27] lib: Rust implementation of SPDM
Date: Tue, 24 Feb 2026 16:54:15 +0100	[thread overview]
Message-ID: <aZ3Jp-8ZjYwgfq0Z@wunner.de> (raw)
In-Reply-To: <aZ2yqpdf8cBGG4Gs@nvidia.com>

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

  reply	other threads:[~2026-02-24 15:54 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-11  3:29 [RFC v3 00/27] lib: Rust implementation of SPDM alistair23
2026-02-11  3:29 ` [RFC v3 01/27] rust: add untrusted data abstraction alistair23
2026-02-11  3:29 ` [RFC v3 02/27] X.509: Make certificate parser public alistair23
2026-02-11  3:29 ` [RFC v3 03/27] X.509: Parse Subject Alternative Name in certificates alistair23
2026-02-11  3:29 ` [RFC v3 04/27] X.509: Move certificate length retrieval into new helper alistair23
2026-02-11  3:29 ` [RFC v3 05/27] certs: Create blacklist keyring earlier alistair23
2026-02-11  3:29 ` [RFC v3 06/27] rust: add bindings for hash.h alistair23
2026-02-19 14:48   ` Gary Guo
2026-03-02 16:18   ` Jonathan Cameron
2026-02-11  3:29 ` [RFC v3 07/27] rust: error: impl From<FromBytesWithNulError> for Kernel Error alistair23
2026-02-19 14:49   ` Gary Guo
2026-03-13  2:20     ` Alistair Francis
2026-03-13 10:35       ` Alice Ryhl
2026-02-11  3:29 ` [RFC v3 08/27] lib: rspdm: Initial commit of Rust SPDM alistair23
2026-03-02 17:09   ` Jonathan Cameron
2026-03-13  3:44     ` Alistair Francis
2026-02-11  3:29 ` [RFC v3 09/27] PCI/CMA: Authenticate devices on enumeration alistair23
2026-02-16  4:25   ` Aksh Garg
2026-02-11  3:29 ` [RFC v3 10/27] PCI/CMA: Validate Subject Alternative Name in certificates alistair23
2026-02-11  3:29 ` [RFC v3 11/27] PCI/CMA: Reauthenticate devices on reset and resume alistair23
2026-02-11  3:29 ` [RFC v3 12/27] lib: rspdm: Support SPDM get_version alistair23
2026-02-11  4:00   ` Wilfred Mallawa
2026-03-03 11:36   ` Jonathan Cameron
2026-03-13  5:35     ` Alistair Francis
2026-03-13  5:53       ` Miguel Ojeda
2026-03-13  5:55         ` Miguel Ojeda
2026-03-16 17:16       ` Jonathan Cameron
2026-02-11  3:29 ` [RFC v3 13/27] lib: rspdm: Support SPDM get_capabilities alistair23
2026-02-11  4:08   ` Wilfred Mallawa
2026-03-03 12:09   ` Jonathan Cameron
2026-03-03 18:07     ` Miguel Ojeda
2026-03-20  4:32     ` Alistair Francis
2026-02-11  3:29 ` [RFC v3 14/27] lib: rspdm: Support SPDM negotiate_algorithms alistair23
2026-03-03 13:46   ` Jonathan Cameron
2026-02-11  3:29 ` [RFC v3 15/27] lib: rspdm: Support SPDM get_digests alistair23
2026-03-03 14:29   ` Jonathan Cameron
2026-02-11  3:29 ` [RFC v3 16/27] lib: rspdm: Support SPDM get_certificate alistair23
2026-03-03 14:51   ` Jonathan Cameron
2026-03-31  2:37     ` Alistair Francis
2026-03-31 13:19       ` Gary Guo
2026-02-11  3:29 ` [RFC v3 17/27] crypto: asymmetric_keys - Load certificate parsing early in boot alistair23
2026-02-11  3:29 ` [RFC v3 18/27] KEYS: Load keyring and certificates " alistair23
2026-02-11  3:29 ` [RFC v3 19/27] PCI/CMA: Support built in X.509 certificates alistair23
2026-02-11  3:29 ` [RFC v3 20/27] crypto: sha: Load early in boot alistair23
2026-03-03 14:52   ` Jonathan Cameron
2026-02-11  3:29 ` [RFC v3 21/27] crypto: ecdsa: " alistair23
2026-03-03 14:54   ` Jonathan Cameron
2026-02-11  3:29 ` [RFC v3 22/27] lib: rspdm: Support SPDM certificate validation alistair23
2026-03-03 15:00   ` Jonathan Cameron
2026-03-31  3:29     ` Alistair Francis
2026-03-31 10:11       ` Miguel Ojeda
2026-04-01  1:48         ` Alistair Francis
2026-04-01 10:37           ` Miguel Ojeda
2026-02-11  3:29 ` [RFC v3 23/27] rust: allow extracting the buffer from a CString alistair23
2026-02-19 14:50   ` Gary Guo
2026-02-11  3:29 ` [RFC v3 24/27] lib: rspdm: Support SPDM challenge alistair23
2026-03-03 16:54   ` Jonathan Cameron
2026-02-11  3:29 ` [RFC v3 25/27] PCI/CMA: Expose in sysfs whether devices are authenticated alistair23
2026-02-11  3:29 ` [RFC v3 26/27] rust: add bindings for hash_info alistair23
2026-02-11  3:29 ` [RFC v3 27/27] rspdm: Multicast received signatures via netlink alistair23
2026-02-19 10:19   ` Lukas Wunner
2026-02-12  5:56 ` [RFC v3 00/27] lib: Rust implementation of SPDM dan.j.williams
2026-02-18  2:12   ` Alistair Francis
2026-04-09  3:39   ` Alistair Francis
2026-04-13  5:42     ` Alistair Francis
2026-04-17  2:35     ` Dan Williams
2026-04-17  4:34       ` Lukas Wunner
2026-04-17  5:20         ` Alistair Francis
2026-05-02  1:34           ` Dan Williams (nvidia)
2026-05-05  8:56             ` Alistair Francis
2026-02-17 23:56 ` Jason Gunthorpe
2026-02-18  2:17   ` Alistair Francis
2026-02-18 23:40     ` dan.j.williams
2026-02-19  0:56       ` Jason Gunthorpe
2026-02-19  5:05         ` dan.j.williams
2026-02-19 12:41           ` Jason Gunthorpe
2026-02-19 14:15             ` Lukas Wunner
2026-02-19 14:31               ` Jason Gunthorpe
2026-02-19 15:07                 ` Lukas Wunner
2026-02-19 17:39                   ` Jason Gunthorpe
2026-02-19 20:07                     ` dan.j.williams
2026-02-20  8:30                     ` Lukas Wunner
2026-02-20 14:10                       ` Jason Gunthorpe
2026-02-21 18:46                         ` Lukas Wunner
2026-02-21 23:29                           ` dan.j.williams
2026-02-23 17:15                             ` Jonathan Cameron
2026-02-23 19:11                               ` dan.j.williams
2026-02-24 14:33                                 ` Jason Gunthorpe
2026-03-05  4:17                                 ` dan.j.williams
2026-03-05 12:48                                   ` Jason Gunthorpe
2026-03-05 19:49                                     ` dan.j.williams
2026-03-09 11:39                                       ` Jonathan Cameron
2026-03-09 12:31                                         ` Jason Gunthorpe
2026-03-09 15:33                                           ` Jonathan Cameron
2026-03-09 15:59                                             ` Jason Gunthorpe
2026-03-09 18:00                                               ` Jonathan Cameron
2026-03-09 20:40                                                 ` Jason Gunthorpe
2026-03-09 23:11                                                   ` DanX Williams
2026-02-24 14:16                           ` Jason Gunthorpe
2026-02-24 15:54                             ` Lukas Wunner [this message]
2026-02-25 14:50                               ` Jason Gunthorpe
2026-02-19 14:40               ` Greg KH
2026-02-20  7:46                 ` Lukas Wunner
2026-02-20  9:14                   ` Greg KH
2026-02-20 11:45                     ` Lukas Wunner
2026-02-20 11:57                       ` Greg KH
2026-02-19  9:34         ` Lukas Wunner
2026-02-19 12:43           ` Jason Gunthorpe
2026-02-19 18:48           ` dan.j.williams
2026-02-19  9:13       ` Lukas Wunner
2026-02-19 18:42         ` dan.j.williams
2026-02-19 11:24   ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aZ3Jp-8ZjYwgfq0Z@wunner.de \
    --to=lukas@wunner.de \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=a.hindborg@kernel.org \
    --cc=aik@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=alistair.francis@wdc.com \
    --cc=alistair23@gmail.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=benno.lossin@proton.me \
    --cc=bhelgaas@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=gary@garyguo.net \
    --cc=jgg@nvidia.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=thomas.fossati@linaro.org \
    --cc=tmgross@umich.edu \
    --cc=wilfred.mallawa@wdc.com \
    --cc=yilun.xu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.