public inbox for stable@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Kanchan Joshi <joshiiitr@gmail.com>,
	Kanchan Joshi <joshi.k@samsung.com>,
	axboe@kernel.dk, sagi@grimberg.me,
	linux-nvme@lists.infradead.org, vincentfu@gmail.com,
	ankit.kumar@samsung.com, cpgs@samsung.com,
	stable@vger.kernel.org, Vincent Fu <vincent.fu@samsung.com>
Subject: Re: [PATCH v3] nvme: fix memory corruption for passthrough metadata
Date: Thu, 12 Oct 2023 06:36:52 +0200	[thread overview]
Message-ID: <20231012043652.GA1368@lst.de> (raw)
In-Reply-To: <ZSbVuuE8YxgwpqM8@kbusch-mbp.dhcp.thefacebook.com>

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.

  reply	other threads:[~2023-10-12  4:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20231006135322epcas5p1c9acf38b04f35017181c715c706281dc@epcas5p1.samsung.com>
2023-10-06 13:47 ` [PATCH v3] nvme: fix memory corruption for passthrough metadata Kanchan Joshi
2023-10-10  7:46   ` Christoph Hellwig
2023-10-10 13:39     ` Kanchan Joshi
2023-10-10 15:31       ` Clay Mayers
2023-10-11  5:03         ` Christoph Hellwig
2023-10-11  5:02       ` Christoph Hellwig
2023-10-11  5:26         ` Kanchan Joshi
2023-10-11  6:36           ` Christoph Hellwig
2023-10-11 17:04         ` Keith Busch
2023-10-12  4:36           ` Christoph Hellwig [this message]
2023-10-12 15:31             ` Keith Busch
2023-10-12 15:46               ` Christoph Hellwig
2023-10-13  2:19               ` Kanchan Joshi
2023-10-13  4:38                 ` Christoph Hellwig
2023-10-13  5:50                   ` Kanchan Joshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231012043652.GA1368@lst.de \
    --to=hch@lst.de \
    --cc=ankit.kumar@samsung.com \
    --cc=axboe@kernel.dk \
    --cc=cpgs@samsung.com \
    --cc=joshi.k@samsung.com \
    --cc=joshiiitr@gmail.com \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    --cc=stable@vger.kernel.org \
    --cc=vincent.fu@samsung.com \
    --cc=vincentfu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox