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;
Subject: Re: [PATCH v28 05/12] LSM: Infrastructure management of the
 superblock
To:     "Serge E. Hallyn" <serge@hallyn.com>,
        =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= <mic@digikod.net>
Cc:     James Morris <jmorris@namei.org>, Jann Horn <jannh@google.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Andrew Morton <akpm@linux-foundation.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Anton Ivanov <anton.ivanov@cambridgegreys.com>,
        Arnd Bergmann <arnd@arndb.de>, Jeff Dike <jdike@addtoit.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Kees Cook <keescook@chromium.org>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Richard Weinberger <richard@nod.at>,
        Shuah Khan <shuah@kernel.org>,
        Vincent Dagonneau <vincent.dagonneau@ssi.gouv.fr>,
        kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org,
        linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org,
        linux-security-module@vger.kernel.org, x86@kernel.org,
        John Johansen <john.johansen@canonical.com>,
        =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= <mic@linux.microsoft.com>,
        Stephen Smalley <stephen.smalley.work@gmail.com>,
        Casey Schaufler <casey@schaufler-ca.com>
References: <20210202162710.657398-1-mic@digikod.net>
 <20210202162710.657398-6-mic@digikod.net>
 <20210205141749.GB17981@mail.hallyn.com>
From:   Casey Schaufler <casey@schaufler-ca.com>
Message-ID: <cb3f290b-e4e6-44b9-9c0d-4f892cc90767@schaufler-ca.com>
Date:   Fri, 5 Feb 2021 08:51:35 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <20210205141749.GB17981@mail.hallyn.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Content-Length: 1622
Precedence: bulk

On 2/5/2021 6:17 AM, Serge E. Hallyn wrote:
> On Tue, Feb 02, 2021 at 05:27:03PM +0100, Micka=C3=ABl Sala=C3=BCn wrot=
e:
>> From: Casey Schaufler <casey@schaufler-ca.com>
>>
>> Move management of the superblock->sb_security blob out of the
>> individual security modules and into the security infrastructure.
>> Instead of allocating the blobs from within the modules, the modules
>> tell the infrastructure how much space is required, and the space is
>> allocated there.
>>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: John Johansen <john.johansen@canonical.com>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>> Signed-off-by: Micka=C3=ABl Sala=C3=BCn <mic@linux.microsoft.com>
>> Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> Acked-by: Serge Hallyn <serge@hallyn.com>
>
> I wonder how many out of tree modules this will impact :)

There are several blobs that have already been converted
to infrastructure management. Not a peep from out-of-tree
module developers/maintainers. I can only speculate that
OOT modules are either less common than we may think, using
alternative data management models (as does eBPF) or
sticking with very old kernels. It's also possible that
they're suffering in silence, which would be sad because
every module that's worth having should be in the tree.

> Actually
> if some new incoming module does an rcu callback to free the
> sb_security, then the security_sb_free will need an update, but
> that seems unlikely.

We're already doing that for the inode blob, so it's
really just a small matter of cut-n-paste and s/inode/sb/
to make that happen.