linux-kernel - Re: [PATCH] PCI/DOE: Expose the DOE protocols via sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKmqyKN2YgtZY3=wr5odoDaLXNv2sD1E4dvqM1DfHC1hxQ4Mtw@mail.gmail.com>
Date:   Tue, 1 Aug 2023 10:03:57 -0400
From:   Alistair Francis <alistair23@...il.com>
To:     Lukas Wunner <lukas@...ner.de>
Cc:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        bhelgaas@...gle.com, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Alistair Francis <alistair.francis@....com>
Subject: Re: [PATCH] PCI/DOE: Expose the DOE protocols via sysfs

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