Received-SPF: pass (google.com: domain of linux-kernel+bounces-215494-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <c58a850758d106f9613c9ba5882e9988712394de.camel@linux.intel.com>
Subject: Re: [PATCH V4 1/3] platform/x86/intel/sdsi: Add ioctl SPDM transport
From: "David E. Box" <david.e.box@linux.intel.com>
Reply-To: david.e.box@linux.intel.com
To: Lukas Wunner <lukas@wunner.de>
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
Date: Fri, 14 Jun 2024 14:17:23 -0700
In-Reply-To: <ZmRSwpRWEgw2GxF1@wunner.de>
References: <20240608034247.181843-1-david.e.box@linux.intel.com>
	 <ZmRSwpRWEgw2GxF1@wunner.de>
Organization: David E. Box
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
Precedence: bulk
MIME-Version: 1.0

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 Protocol=
s 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.
> > > >=20
> > > > Add an ioctl interface for sending SPDM messages through the On Dem=
and
> > > > mailbox. Provides commands to get a list of SPDM enabled devices, g=
et
> > > > the
> > > > message size limits for SPDM Requesters and Responders, and perform=
 an
> > > > SPDM
> > > > message exchange.
> >=20
> > 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).=C2=A0 It is also possible to set the next requester no=
nce
> > from user space if the kernel is mistrusted to always use a fresh nonce=
.
> >=20
> > See the two top-most commits on this branch:
> >=20
> > https://github.com/l1k/linux/commits/doe
> >=20
> > I intend to submit these patches by end of June.=C2=A0 There are two th=
ings
> > still missing before I can resubmit:=C2=A0 Exposure of certificate chai=
ns in
> > sysfs (currently a WIP) and expiration of older signatures (to limit th=
e
> > amount of memory consumed for their storage).=C2=A0 After submission, I=
 intend
> > to forward-port your measurement patch in Q3.
> >=20
> > I recall S3M folks rejected use of the in-kernel SPDM implementation fo=
r
> > SDSi because it previously didn't allow for re-verification of signatur=
es
> > by user space.

Yes, this was the main reason for not going with the in-kernel solution.

> > =C2=A0 Perhaps with the added functionality they'll reconsider?

Q3 is too late for their needs. They want to proceed with the driver soluti=
on.
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

> >=20
> > Thanks,
> >=20
> > Lukas