[PATCH v3] nvme: fix memory corruption for passthrough metadata
Christoph Hellwig
hch at lst.de
Wed Oct 11 21:36:52 PDT 2023
On Wed, Oct 11, 2023 at 11:04:58AM -0600, Keith Busch wrote:
> > > Given the way things are in NVMe, I do not find a better way.
> > > Maybe another day for commands that do (or can do) things very
> > > differently for nlb and PI representation.
> >
> > Fixing just a subset of these problems is pointless. If people want
> > to use metadata on vendor specific commands they need to work with
> > NVMe to figure out a generic way to pass the length.
>
> NVMe already tried to solve that with NDT and NDM fields, but no vendor
> implemented it. Maybe just require SGL's for passthrough IO since that
> encodes the buffer sizes.
How is that going to help us with metadata where neither we, nor most
devices support SGLs?
> I don't think it's reasonable for the driver to decode every passthrough
> command to validate the data lengths, or reject ones that we don't know
> how to decode. SG_IO doesn't do that either.
I don't want that either, but what can we do against a (possibly
unprivileged) user corrupting data?
SCSI has it much either because it has an explicit data transfer length
(outside the CDB) instead of trying to build it from information that
differs per opcode. One of the many places where it shows that NVMe
is a very sloppy and badly thought out protocol.
More information about the Linux-nvme
mailing list