On 7/20/22 9:06 AM, Paul Moore wrote:

On Mon, Jul 18, 2022 at 1:12 PM Casey Schaufler [off-list ref] wrote:

quoted

On 7/15/2022 8:33 PM, Paul Moore wrote:

quoted

On Fri, Jul 15, 2022 at 3:52 PM Paul Moore [off-list ref] wrote:

quoted

On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe [off-list ref] wrote:

quoted

On 7/15/22 1:16 PM, Luis Chamberlain wrote:

quoted

io-uring cmd support was added through ee692a21e9bf ("fs,io_uring:
add infrastructure for uring-cmd"), this extended the struct
file_operations to allow a new command which each subsystem can use
to enable command passthrough. Add an LSM specific for the command
passthrough which enables LSMs to inspect the command details.

This was discussed long ago without no clear pointer for something
conclusive, so this enables LSMs to at least reject this new file
operation.

From an io_uring perspective, this looks fine to me. It may be easier if
I take this through my tree due to the moving of the files, or the
security side can do it but it'd have to then wait for merge window (and
post io_uring branch merge) to do so. Just let me know. If done outside
of my tree, feel free to add:

I forgot to add this earlier ... let's see how the timing goes, I
don't expect the LSM/Smack/SELinux bits to be ready and tested before
the merge window opens so I'm guessing this will not be an issue in
practice, but thanks for the heads-up.

I have a patch that may or may not be appropriate. I ran the
liburing tests without (additional) failures, but it looks like
there isn't anything there testing uring_cmd. Do you have a
test tucked away somewhere I can use?

I just had a thought, would the io_uring folks be opposed if I
submitted a patch to add a file_operations:uring_cmd for the null
character device?  A simple uring_cmd noop seems to be in keeping with
the null device, and it would make testing the io_uring CMD
functionality much easier as it would not rely on a specific device.

I think something like this would be in keeping with the null driver:

  static int uring_cmd_null(struct io_uring_cmd *ioucmd, unsigned int
issue_flags)
  {
    return 0;
  }

Thoughts?

I think that's a good idea. We're adding an nvme based test for
liburing, but that's to be able to test the whole passthrough part, not
just uring_cmd in particular.

Adding a dummy one to null/zero makes sense for test purposes.

-- 
Jens Axboe