linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: "David E. Box" <david.e.box@linux.intel.com>
Cc: linux-doc@vger.kernel.org, ilpo.jarvinen@linux.intel.com,
	hdegoede@redhat.com, linux-kernel@vger.kernel.org,
	platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH V4 1/3] platform/x86/intel/sdsi: Add ioctl SPDM transport
Date: Mon, 1 Jul 2024 10:09:29 +0200	[thread overview]
Message-ID: <ZoJkOYwmvx3SnEr6@wunner.de> (raw)
In-Reply-To: <c58a850758d106f9613c9ba5882e9988712394de.camel@linux.intel.com>

On Fri, Jun 14, 2024 at 02:17:23PM -0700, David E. Box wrote:
> On Sat, 2024-06-08 at 14:46 +0200, Lukas Wunner wrote:
> > > On Fri, Jun 07, 2024 at 08:42:45PM -0700, David E. Box wrote:
> > > > > Intel On Demand adds attestation and firmware measurement retrieval
> > > > > services through use of the protocols defined the Security Protocols
> > > > > and Data Measurement (SPDM) specification.
> > > 
> > > I've amended the in-kernel SPDM implementation to expose signatures
> > > received from the device in sysfs, together with all ancillary data
> > > necessary to re-verify signatures from user space (transcript, hash
> > > algorithm, etc). It is also possible to set the next requester nonce
> > > from user space if the kernel is mistrusted to always use a fresh nonce.
> > > 
> > > I recall S3M folks rejected use of the in-kernel SPDM implementation for
> > > SDSi because it previously didn't allow for re-verification of signatures
> > > by user space.
> 
> Yes, this was the main reason for not going with the in-kernel solution.
> 
> > > Perhaps with the added functionality they'll reconsider?
> 
> Q3 is too late for their needs. They want to proceed with the driver
> solution. We can push for using the in-kernel solution when it is
> upstreamed. I think this will be possible when they extend support
> beyond SPDM v1.0.

Fair enough.  I've submitted v2 of the in-kernel SPDM library yesterday:

https://lore.kernel.org/all/cover.1719771133.git.lukas@wunner.de/

It would be good to know if the ABI for exposure of certificates and
signatures makes sense and would integrate easily with SDSi user space
tooling.  Or if it does not, how I should change it.  So I'd love
to hear feedback.  The ABI documentation is contained in these patches:

* [PATCH v2 12/18] PCI/CMA: Expose certificates in sysfs
  https://lore.kernel.org/all/e42905e3e5f1d5be39355e833fefc349acb0b03c.1719771133.git.lukas@wunner.de/
* [PATCH v2 15/18] PCI/CMA: Expose a log of received signatures in sysfs
  https://lore.kernel.org/all/77f549685f994981c010aebb1e9057aa3555b18a.1719771133.git.lukas@wunner.de/
* [PATCH v2 16/18] spdm: Limit memory consumed by log of received signatures
  https://lore.kernel.org/all/2e6ee6670a5d450bc880e77a892ea0227a2cc3b4.1719771133.git.lukas@wunner.de/
* [PATCH v2 17/18] spdm: Authenticate devices despite invalid certificate chain
  https://lore.kernel.org/all/dff8bcb091a3123e1c7c685f8149595e39bbdb8f.1719771133.git.lukas@wunner.de/
* [PATCH v2 18/18] spdm: Allow control of next requester nonce through sysfs
  https://lore.kernel.org/all/ee3248f9f8d60cff9106a5a46c5f5d53ac81e60a.1719771133.git.lukas@wunner.de/

This doesn't yet contain measurement retrieval, which I understand
is needed for SDSi.  I intend to add it this (third) quarter.

Thanks,

Lukas

  reply	other threads:[~2024-07-01  8:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-08  3:42 [PATCH V4 1/3] platform/x86/intel/sdsi: Add ioctl SPDM transport David E. Box
2024-06-08  3:42 ` [PATCH V4 2/3] tools/arch/x86/intel_sdsi: Rework Makefile David E. Box
2024-06-08  3:42 ` [PATCH V4 3/3] tools/arch/x86/intel_sdsi: Add attestation support David E. Box
2024-07-06 14:03   ` Ilpo Järvinen
2024-06-08 12:46 ` [PATCH V4 1/3] platform/x86/intel/sdsi: Add ioctl SPDM transport Lukas Wunner
2024-06-14 21:17   ` David E. Box
2024-07-01  8:09     ` Lukas Wunner [this message]
2024-07-06 14:05 ` Ilpo Järvinen

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=ZoJkOYwmvx3SnEr6@wunner.de \
    --to=lukas@wunner.de \
    --cc=david.e.box@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).