[RFC 0/2] nvme command whitelisting

[Kanchan Joshi <joshi.k@samsung.com>]

Hi All,

Passthrough has turned much more useful than it used to be. Specifically
it has begun to offer
- Availability: via /dev/ngXnY, for any current/future nvme command-set
- Efficiency: via io_uring driven passthrough

Now that user-space has more reasons to pick this path than before, the
existing CAP_SYS_ADMIN based checks are worth a revisit. Nvme-native
applications requires 'querying' certain information (such as lba-format,
namespace size, log-pages/get-feature etc.) to start doing io on the
device.
Currently both io and admin commands are kept under a
coarse-granular CAP_SYS_ADMIN check, even if device has successfully been
opened with write access. In example below, ng0n1 appears as if it may
allow unprivileged read/write operations but it does not (same as ng0n2).

$ ls -l /dev/ng*
crw-rw-rw- 1 root root 242, 0 Sep  9 19:20 /dev/ng0n1
crw------- 1 root root 242, 1 Sep  9 19:20 /dev/ng0n2

This series attempts a shift from CAP_SYS_ADMIN to fine-granular whitelisting,
similar to what SCSI already has.

Patch 1: contains the whitelisting implementation. Patch-description
outlines the policy.

Patch 2: Changes the sync/async passthrough to employ whitelisting.

Purpose of the RFC is to seek feedback on below two points and path
forward hereon.
- Whitelisting scheme as described in patch 1
- Driver-defined static list (current one) vs dynamic list
  (mutable through sysfs or new admin-only ioctl)

Kanchan Joshi (2):
  nvme: add whitelisting infrastructure
  nvme: CAP_SYS_ADMIN to nvme-whitelisting

 drivers/nvme/host/ioctl.c | 106 ++++++++++++++++++++++++++------------
 1 file changed, 74 insertions(+), 32 deletions(-)

-- 
2.25.1