From: Kanchan Joshi <joshi.k@samsung.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
kbusch@kernel.org, sagi@grimberg.me,
linux-nvme@lists.infradead.org, j.granados@samsung.com,
javier.gonz@samsung.com
Subject: Re: [RFC 1/2] nvme: add whitelisting infrastructure
Date: Thu, 22 Sep 2022 12:14:39 +0530 [thread overview]
Message-ID: <20220922064439.GA23511@test-zns> (raw)
In-Reply-To: <20220910053536.GB23158@lst.de>
[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]
On Sat, Sep 10, 2022 at 07:35:36AM +0200, Christoph Hellwig wrote:
>On Fri, Sep 09, 2022 at 10:55:45AM -0600, Jens Axboe wrote:
>> > +bool nvme_io_cmd_allowed(u8 opcode, fmode_t mode)
>> > +{
>> > + /* allow write/read based on what was allowed for open */
>> > + /* TBD: try to use nvme_is_write() here */
>> > + if (opcode & 1)
>> > + return (mode & FMODE_WRITE);
>> > + else
>> > + return (mode & FMODE_READ);
>> > +}
>>
>> The read/write distinction doesn't make a lot of sense to me. You've
>> already been able to open the device at this point. It would only make
>> sense to limit some things based on FMODE_WRITE imho, not FMODE_READ.
>
>True. Note that the I/O queues can also send fabrics commands, which
>we must exclude, and I'd also very much exclude vendor specific commands
>as we can't trust them at all - they aren't even guaranteed to interpret
>the nsid field like the standard ones.
I see.
So next version (with reduced scope limited to io-cmd only) will -
a) not allow fabrics and VS commands at all
b) allow write-cmds iff FMODE_WRITE is set
c) allow read-cmds without looking at FMODE_READ
Please correct if something sounds amiss in that.
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2022-09-22 6:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220909164315epcas5p17de296f5c0796ecf92fe3d0e4a020901@epcas5p1.samsung.com>
2022-09-09 16:33 ` [RFC 0/2] nvme command whitelisting Kanchan Joshi
2022-09-09 16:33 ` [RFC 1/2] nvme: add whitelisting infrastructure Kanchan Joshi
2022-09-09 16:55 ` Jens Axboe
2022-09-10 5:35 ` Christoph Hellwig
2022-09-22 6:44 ` Kanchan Joshi [this message]
2022-09-09 16:57 ` Keith Busch
2022-09-10 5:34 ` Christoph Hellwig
2022-09-22 7:17 ` Kanchan Joshi
2022-09-18 16:19 ` Joel Granados
2022-09-26 16:16 ` Keith Busch
2022-10-03 11:54 ` Joel Granados
2022-09-21 10:58 ` Joel Granados
2022-09-09 16:33 ` [RFC 2/2] nvme: CAP_SYS_ADMIN to nvme-whitelisting Kanchan Joshi
2022-09-18 16:49 ` [RFC 0/2] nvme command whitelisting Joel Granados
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=20220922064439.GA23511@test-zns \
--to=joshi.k@samsung.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=j.granados@samsung.com \
--cc=javier.gonz@samsung.com \
--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.