Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <705fde50-37a6-49ed-b9c2-c9107cd88189@t-8ch.de>
In-Reply-To: <705fde50-37a6-49ed-b9c2-c9107cd88189@t-8ch.de>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Wed, 15 Sep 2021 09:47:25 -0700
Message-ID: <CALCETrUM0cko=5ki-Dd402DNFU2TmgnJTz_vfrsaofkGD-1kmA@mail.gmail.com>
Subject: Re: [RFC] Expose request_module via syscall
To:     =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= <thomas@t-8ch.de>
Cc:     Linux API <linux-api@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Luis Chamberlain <mcgrof@kernel.org>,
        Jessica Yu <jeyu@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Sep 15, 2021 at 8:50 AM Thomas Wei=C3=9Fschuh <thomas@t-8ch.de> wro=
te:
>
> 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 fla=
gs);
> 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 modul=
es.
> 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.

I feel like I'm missing something, and I don't understand the purpose
of this syscall.  Wouldn't the right solution be for the container to
have a stub module loader (maybe doable with a special /sbin/modprobe
or maybe a kernel patch would be needed, depending on the exact use
case) and have the stub call out to the container manager to request
the module?  The container manager would check its security policy and
load the module or not load it as appropriate.

--Andy