linux-kernel - Re: [PATCH V4 1/3] platform/x86/intel/sdsi: Add ioctl SPDM transport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Mon, 1 Jul 2024 10:09:29 +0200
From: Lukas Wunner <lukas@...ner.de>
To: "David E. Box" <david.e.box@...ux.intel.com>
Cc: linux-doc@...r.kernel.org, ilpo.jarvinen@...ux.intel.com,
	hdegoede@...hat.com, linux-kernel@...r.kernel.org,
	platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH V4 1/3] platform/x86/intel/sdsi: Add ioctl SPDM transport

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