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
