Re: [RFC 1/2] nvme: add whitelisting infrastructure

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 --]