On Mon, Jul 31, 2023 at 1:52 PM Lukas Wunner <lukas@xxxxxxxxx> 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
