Messages in this thread | | | From | Alistair Francis <> | Date | Tue, 1 Aug 2023 10:03:57 -0400 | Subject | Re: [PATCH] PCI/DOE: Expose the DOE protocols via sysfs |
| |
On Mon, Jul 31, 2023 at 1:52 PM Lukas Wunner <lukas@wunner.de> wrote: > > On Mon, Jul 31, 2023 at 11:30:29AM -0400, Alistair Francis wrote: > > Yep, a big benefit is lspci or other userspace tools to be able to see > > what DOE protocols are supported. > > Fair enough, but please make that motivation explicit in the commit > message.
Fixed in v2
> > > > I also have plans to expose DOE mailboxes to userspace. That way we > > can run the SPDM requester code (using libspdm) in userspace to > > communicate with devices using SPDM. That will allow device > > authentication for example. > > That duplicates our effort to bring up authentication in the kernel: > https://github.com/l1k/linux/commits/doe
That's great!
> > We had a lengthy debate on the pros and cons of doing SPDM in-kernel > versus in user space. We realized that when resuming a device from > D3cold or recovering it after reset, the user space component performing > SPDM authentication might reside on the device (disk, network) being > resumed or reset, preventing its execution. > > When resuming from system sleep, devices need to be reauthenticated > during the ->resume_noirq phase, i.e. with device interrupts disabled, > as drivers are allowed access to devices already in that phase. > So authentication (and encryption establishment) needs to happen this > early, when user space isn't available yet.
Yeah, I had the same debate. Resume/suspend and reset are good points though.
Do you plan on supporting all SPDM commands in the kernel and then passing information to userspace as required?
Alistair
> > See the commit message of "PCI/CMA: Reauthenticate devices on reset > and resume" on the above-linked branch for details. > > Thanks, > > Lukas
| |