Re: [RFC PATCH 0/1] DOE usage with pcie/portdrv

[Dan Williams <dan.j.williams@intel.com>]

On Wed, May 18, 2022 at 6:44 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Sat, May 14, 2022 at 03:55:21PM +0200, Lukas Wunner wrote:
> > Circling back to the SPDM/IDE topic, while NVMe is now capable of
> > reliably recovering from errors, it does expect the kernel to handle
> > recovery within a few seconds.  I'm not sure we can continue to
> > guarantee that if the kernel depends on user space to perform
> > re-authentication with SPDM after reset.  That's another headache
> > that we could avoid with in-kernel SPDM authentication.
>
> I wonder if we need kernel bundled and tightly controlled userspace
> code for these kinds of things (also for NVMe/NFS TLS).  That is,
> bundle a userspace ELF file or files with a module which is unpacked
> to or accessible by a ramfs-style file systems.  Then allow executing
> it without any interaction with the normal userspace, and non-pagable
> memory.  That way we can reuse existing userspace code, have really
> nice address space isolation but avoid all the deadlock potential
> of normal userspace code.  And I don't think it would be too hard to
> implement either.

Yes, I also want something like this for mitigating the vulnerability
surface of things like PRM [1], where platform vendors are looking to
move more runtime helpers out of SMM mode and into ring0. I would
rather see those routines move all the way into ring3.

[1]: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf