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

["David E. Box" <david.e.box@linux.intel.com>]

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