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

[Lukas Wunner <lukas@wunner.de>]

On Wed, May 18, 2022 at 06:43:39AM -0700, Christoph Hellwig 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.

Just as a reminder, on resume from system sleep, IDE needs to be
set up by pci_pm_resume_noirq() to comply with the existing assumption
that a PCI driver's ->resume_noirq callback may access the device.

At that point (device) interrupts are disabled, so it's not possible
to e.g. read certificates from disk or perform an OCSP request.
So the bundled userspace code would have to conform to a number of
severe restrictions to avoid resume issues.

Thanks,

Lukas