On Mon, Nov 21, 2022 at 11:53:17AM -0800, Luis Chamberlain wrote:
> On Thu, Nov 17, 2022 at 05:10:07PM -0500, Paul Moore wrote:
> > On Thu, Nov 17, 2022 at 4:40 AM Joel Granados <j.granados@samsung.com> wrote:
> > > On Wed, Nov 16, 2022 at 02:21:14PM -0500, Paul Moore wrote:
> > 
> > ...
> > 
> > > > * As we discussed previously, the real problem is the fact that we are
> > > > missing the necessary context in the LSM hook to separate the
> > > > different types of command targets.  With traditional ioctls we can
> > > > look at the ioctl number and determine both the type of
> > > > device/subsystem/etc. as well as the operation being requested; there
> > > > is no such information available with the io_uring command
> > > > passthrough.  In this sense, the io_uring command passthrough is
> > > > actually worse than traditional ioctls from an access control
> > > > perspective.  Until we have an easy(ish)[1] way to determine the
> > > > io_uring command target type, changes like the one suggested here are
> > > > going to be doomed as each target type is free to define their own
> > > > io_uring commands.
> > >
> > > The only thing that comes immediately to mind is that we can have
> > > io_uring users define a function that is then passed to the LSM
> > > infrastructure. This function will have all the logic to give relative
> > > context to LSM. It would be general enough to fit all the possible commands
> > > and the logic would be implemented in the "drivers" side so there is no
> > > need for LSM folks to know all io_uring users.
> > 
> > Passing a function pointer to the LSM to fetch, what will likely be
> > just a constant value, seems kinda ugly, but I guess we only have ugly
> > options at this point.
> 
> I am not sure if this helps yet, but queued on modules-next we now have
> an improvement in speed of about 1500x for kallsyms_lookup_name(), and
> so symbol lookups are now fast. Makes me wonder if a type of special
> export could be drawn up for specific calls which follow a structure
> and so the respective lsm could be inferred by a prefix instead of
> placing the calls in-place. Then it would not mattter where a call is
> used, so long as it would follow a specific pattern / structure with
> all the crap you need on it.

This is very good to know. Thx for putting this in the foreground.
This problems CAN be seen as two:
1. Knowing where the io_uring is coming from (user, file, drivers...)
2. Calling the appropriate callback (ublk callback or nvme callback...)

In this sense we might be able to use kallsysms_lookup_name() to do the
callback to a relevant driver.

I have posted a version 2 of the RFC without using
kallsysms_lookup_name, but I'll keep it in the back of my mind.

Best
> 
>   Luis