All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Thomas Weißschuh" <thomas@t-8ch.de>
Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	Luis Chamberlain <mcgrof@kernel.org>,
	Jessica Yu <jeyu@kernel.org>
Subject: Re: [RFC] Expose request_module via syscall
Date: Wed, 15 Sep 2021 18:02:49 +0200	[thread overview]
Message-ID: <YUIZKagx0bjJ3PEm@kroah.com> (raw)
In-Reply-To: <705fde50-37a6-49ed-b9c2-c9107cd88189@t-8ch.de>

On Wed, Sep 15, 2021 at 05:49:34PM +0200, Thomas Weißschuh wrote:
> Hi,
> 
> I would like to propose a new syscall that exposes the functionality of
> request_module() to userspace.
> 
> Propsed signature: request_module(char *module_name, char **args, int flags);
> Where args and flags have to be NULL and 0 for the time being.
> 
> Rationale:
> 
> We are using nested, privileged containers which are loading kernel modules.
> Currently we have to always pass around the contents of /lib/modules from the
> root namespace which contains the modules.
> (Also the containers need to have userspace components for moduleloading
> installed)
> 
> The syscall would remove the need for this bookkeeping work.

So you want any container to have the ability to "bust through" the
containers and load a module from the "root" of the system?

That feels dangerous, why not just allow a mount of /lib/modules into
the containers that you want to be able to load a module?

Why are modules somehow "special" here, they are just a resource that
has to be allowed (or not) to be accessed by a container like anything
else on a filesystem.

thanks,

greg k-h

  reply	other threads:[~2021-09-15 16:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15 15:49 [RFC] Expose request_module via syscall Thomas Weißschuh
2021-09-15 16:02 ` Greg KH [this message]
2021-09-15 16:28   ` Thomas Weißschuh
2021-09-15 16:47 ` Andy Lutomirski
2021-09-16  9:27   ` Christian Brauner
2021-09-18 18:47     ` Andy Lutomirski
2021-09-19  7:56       ` Thomas Weißschuh
2021-09-19 14:37         ` Andy Lutomirski
2021-09-20 14:51           ` Thomas Weißschuh
2021-09-20 16:59             ` Luis Chamberlain
2021-09-20 18:36               ` Andy Lutomirski
2021-09-22 12:25                 ` Christian Brauner
2021-09-22 15:34                   ` Andy Lutomirski
2021-09-22 15:52                     ` Christian Brauner
2021-09-22 20:06                       ` Andy Lutomirski
2021-09-24 13:19                         ` Christian Brauner
2021-09-24 23:04                           ` Andy Lutomirski
2021-10-24  9:38         ` Thomas Weißschuh

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=YUIZKagx0bjJ3PEm@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=jeyu@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=thomas@t-8ch.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.