From: Kanchan Joshi <joshi.k@samsung.com>
To: Christoph Hellwig <hch@lst.de>
Cc: kbusch@kernel.org, sagi@grimberg.me, linux-nvme@lists.infradead.org
Subject: Re: [PATCH] nvme: don't allow unprivileged Write Zeroes passthrough on read-only FDs
Date: Thu, 1 Dec 2022 04:50:12 +0530 [thread overview]
Message-ID: <20221130232012.GA24451@test-zns> (raw)
In-Reply-To: <20221129090016.1311006-1-hch@lst.de>
[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]
On Tue, Nov 29, 2022 at 10:00:16AM +0100, Christoph Hellwig wrote:
>Unfortunately Write Zeroes is coded as a no data transfer opcode in NVMe,
>so don't allow it on a read-only FD for unprivileged users.
>
>Fixes: 855b7717f44b ("nvme: fine-granular CAP_SYS_ADMIN for nvme io commands")
>Signed-off-by: Christoph Hellwig <hch@lst.de>
>---
> drivers/nvme/host/ioctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/nvme/host/ioctl.c b/drivers/nvme/host/ioctl.c
>index 9550a69029b368..8aefe9c904dc9a 100644
>--- a/drivers/nvme/host/ioctl.c
>+++ b/drivers/nvme/host/ioctl.c
>@@ -45,7 +45,7 @@ static bool nvme_cmd_allowed(struct nvme_ns *ns, struct nvme_command *c,
> * special file is open for writing, but always allow I/O commands that
> * transfer data from the controller.
> */
>- if (nvme_is_write(c))
>+ if (nvme_is_write(c) || c->common.opcode == nvme_cmd_write_zeroes)
> return mode & FMODE_WRITE;
I was thinking why check for write_zeroes should not go inside nvme_is_write
itself. Then I saw various callers of nvme_is_write, and that killed the
thought.
Another thought is - does it make sense to include nvme_cmd_flush too?
That is also declared as no-data-transfer in spec. Flush alone can't
make any difference when writes are not allowed in first place. So this
is about whether we care for empty flushes.
And on spec - not sure whether the criteria has changed of late. copy
command also does not involve data-transfer but bit is set there.
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2022-11-30 23:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20221129090709epcas5p21176e0faa7914cea52aab2e8fa95c2db@epcas5p2.samsung.com>
2022-11-29 9:00 ` [PATCH] nvme: don't allow unprivileged Write Zeroes passthrough on read-only FDs Christoph Hellwig
2022-11-29 17:54 ` Chaitanya Kulkarni
2022-11-30 8:34 ` Sagi Grimberg
2022-11-30 23:20 ` Kanchan Joshi [this message]
2022-12-01 16:07 ` Keith Busch
2022-12-01 16:09 ` Christoph Hellwig
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=20221130232012.GA24451@test-zns \
--to=joshi.k@samsung.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.