From: Jens Axboe <[email protected]>
To: Paul Moore <[email protected]>,
Casey Schaufler <[email protected]>,
Luis Chamberlain <[email protected]>
Cc: [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected]
Subject: Re: [PATCH v2] lsm,io_uring: add LSM hooks for the new uring_cmd file op
Date: Wed, 20 Jul 2022 09:11:19 -0600 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAHC9VhQeScpuhFU=E+Q7Ewyd0Ta-VLA+45zQF9-g-Ae+CN1fgA@mail.gmail.com>
On 7/20/22 9:06 AM, Paul Moore wrote:
> On Mon, Jul 18, 2022 at 1:12 PM Casey Schaufler <[email protected]> wrote:
>> On 7/15/2022 8:33 PM, Paul Moore wrote:
>>> On Fri, Jul 15, 2022 at 3:52 PM Paul Moore <[email protected]> wrote:
>>>> On Fri, Jul 15, 2022 at 3:28 PM Jens Axboe <[email protected]> wrote:
>>>>> On 7/15/22 1:16 PM, Luis Chamberlain wrote:
>>>>>> 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
next prev parent reply other threads:[~2022-07-20 15:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 19:16 [PATCH v2] lsm,io_uring: add LSM hooks for the new uring_cmd file op Luis Chamberlain
2022-07-15 19:28 ` Jens Axboe
2022-07-15 19:52 ` Paul Moore
2022-07-16 3:33 ` Paul Moore
2022-07-18 17:12 ` Casey Schaufler
2022-07-18 21:52 ` Paul Moore
2022-07-19 4:47 ` Kanchan Joshi
2022-07-19 13:54 ` Ming Lei
2022-07-20 15:06 ` Paul Moore
2022-07-20 15:11 ` Jens Axboe [this message]
2022-08-10 18:14 ` Luis Chamberlain
2022-08-10 18:39 ` Paul Moore
2022-08-10 18:52 ` Luis Chamberlain
2022-08-10 19:26 ` Casey Schaufler
2022-08-10 22:15 ` Paul Moore
2022-08-10 22:14 ` Paul Moore
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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