[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c58a850758d106f9613c9ba5882e9988712394de.camel@linux.intel.com>
Date: Fri, 14 Jun 2024 14:17:23 -0700
From: "David E. Box" <david.e.box@...ux.intel.com>
To: Lukas Wunner <lukas@...ner.de>
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
Hi Lukas,
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. SPDM messages exchanges are used
> > > > to
> > > > authenticate On Demand hardware and to retrieve signed measurements of
> > > > the
> > > > NVRAM state used to track feature provisioning and the NVRAM state used
> > > > for
> > > > metering services. These allow software to verify the authenticity of
> > > > the
> > > > On Demand hardware as well as the integrity of the reported silicon
> > > > configuration.
> > > >
> > > > Add an ioctl interface for sending SPDM messages through the On Demand
> > > > mailbox. Provides commands to get a list of SPDM enabled devices, get
> > > > the
> > > > message size limits for SPDM Requesters and Responders, and perform an
> > > > SPDM
> > > > message exchange.
> >
> > 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.
> >
> > See the two top-most commits on this branch:
> >
> > https://github.com/l1k/linux/commits/doe
> >
> > I intend to submit these patches by end of June. There are two things
> > still missing before I can resubmit: Exposure of certificate chains in
> > sysfs (currently a WIP) and expiration of older signatures (to limit the
> > amount of memory consumed for their storage). After submission, I intend
> > to forward-port your measurement patch in Q3.
> >
> > 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.
David
> >
> > Thanks,
> >
> > Lukas
Powered by blists - more mailing lists