[RFC 1/2] nvme: add whitelisting infrastructure
Kanchan Joshi
joshi.k at samsung.com
Wed Sep 21 23:44:39 PDT 2022
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.
More information about the Linux-nvme
mailing list