From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A953C433EF for ; Wed, 15 Sep 2021 16:47:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 32667610E9 for ; Wed, 15 Sep 2021 16:47:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230251AbhIOQtA (ORCPT ); Wed, 15 Sep 2021 12:49:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:49170 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229489AbhIOQs6 (ORCPT ); Wed, 15 Sep 2021 12:48:58 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B0EDE610E9 for ; Wed, 15 Sep 2021 16:47:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1631724459; bh=RXpsF/VO6GEdjb1aQhtYiJKHMct/U0k37GgDFDGgrR4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=j05dwuutr3ixumWPZWdZIcn+eEOt/vnSb1TnGP9o2pp+YwKIGCoNzYsjFCOUVo4pz WjPRbZJqT4GU1lVr/pFLN4xZnFgWQxLEbPPm6waSRAsmR7qGtgkvSdod5R14MlWOjd PMnpP7w1LZK4hxdH7iLxck8zaw3Hw9lZ5SZBQqOSLbNuPtuRvBWgPtgeBu101aaefw qr1jO7Jlu0/UrCsWuOSXL8YoCi58n24Pb/MD5PEz4MFJctJrqxlXfPL+vKQiQPWz8E KKagKKIwaKxlQOh6TIxx73aYyPRl5gleaZZw6jpUPwPFl184cl6+hJZ0w5ueCozUll GyqVDHQy2Dg3g== Received: by mail-ed1-f50.google.com with SMTP id v22so1763216edd.11 for ; Wed, 15 Sep 2021 09:47:39 -0700 (PDT) X-Gm-Message-State: AOAM531PgMxPWfyILbGKJMHWUeKPT9jbD7FxoyScjnCG2e9WLPbLHyIj OhpnyDxnlRdN3BUcyAMA/WsgRdu4ZIit6RuU4RECag== X-Google-Smtp-Source: ABdhPJynY4FSVmglrMDA36UZlrr7peMUTfEqx8YeTiK3u74IyWamFT9pPKsO1KiexgAnay+21MZnBhxbl1CrQQs4Aow= X-Received: by 2002:a17:906:1557:: with SMTP id c23mr926887ejd.371.1631724458312; Wed, 15 Sep 2021 09:47:38 -0700 (PDT) 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 Date: Wed, 15 Sep 2021 09:47:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] Expose request_module via syscall To: =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= Cc: Linux API , LKML , Luis Chamberlain , Jessica Yu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 15, 2021 at 8:50 AM Thomas Wei=C3=9Fschuh 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