[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