From: Christoph Hellwig <hch@lst.de>
To: Keith Busch <kbusch@kernel.org>
Cc: Kanchan Joshi <joshi.k@samsung.com>,
hch@lst.de, axboe@kernel.dk, 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: Sat, 10 Sep 2022 07:34:03 +0200 [thread overview]
Message-ID: <20220910053403.GA23158@lst.de> (raw)
In-Reply-To: <YxtwiDE0amT5DuNt@kbusch-mbp.dhcp.thefacebook.com>
On Fri, Sep 09, 2022 at 10:57:44AM -0600, Keith Busch wrote:
> On Fri, Sep 09, 2022 at 10:03:06PM +0530, Kanchan Joshi wrote:
> > +bool nvme_admin_cmd_allowed(u8 opcode, fmode_t mode)
> > +{
> > + /* allowed few read-only commands post the mode check */
> > + switch (opcode) {
> > + case nvme_admin_identify:
> > + case nvme_admin_get_log_page:
> > + case nvme_admin_get_features:
> > + return (mode & FMODE_READ);
>
> Some log pages have read side effects, like Namespace Changed List or anything
> latched to RAE. That opcode seems a little more dangerous than the others in
> the whitelist.
Yes. Some of the log pages (e.g. the persistent error log, or the LBA
status log) are also getting really close to covert channels. Can we
please have really good justifications for why we'd whitelist anything
on the admin side?
next prev parent reply other threads:[~2022-09-10 5:34 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
[not found] ` <CGME20220909164318epcas5p15d022bfc15bb4f22dbe4fb424576243d@epcas5p1.samsung.com>
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
2022-09-09 16:57 ` Keith Busch
2022-09-10 5:34 ` Christoph Hellwig [this message]
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
[not found] ` <CGME20220909164322epcas5p392a312c882521eb8148ca8503999dcb6@epcas5p3.samsung.com>
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=20220910053403.GA23158@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=j.granados@samsung.com \
--cc=javier.gonz@samsung.com \
--cc=joshi.k@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).