[RFC] LSM deprecation / removal policies

[Paul Moore]

On Thu, May 8, 2025 at 10:14 AM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
> On 2025/05/08 5:14, Paul Moore wrote:
> > On Wed, May 7, 2025 at 12:24 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> >> On 5/7/2025 4:06 AM, Tetsuo Handa wrote:
> >>> The problem is that the owner out-of-tree BPF LSM solution cannot join the
> >>> discussion about LSM hooks being modified/removed. That is, out-of-tree BPF
> >>> LSMs will be forced to stay as unstable as out-of-tree non-BPF LSMs.
> >>
> >> The same issue applies to out-of-tree filesystems and device drivers.
> >> There's no problem that is new or unique to the LSM interface here.
> >
> > Exactly.  Out-of-tree kernel code is out-of-tree code.  Tetsuo, we've
> > already had this discussion many times, and my opinion on this has not
> > changed since we last discussed this topic.
> >
>
> Out-of-tree filesystems and out-of-tree device drivers can be built as
> loadable kernel modules whereas out-of-tree LSM modules cannot be legally
> built as loadable kernel modules. And replacing the whole kernel in order to
> enable out-of-tree LSM modules (or in-tree but not-builtin LSM modules) is
> a big barrier.
>
> Also, how many LSM modules have been accepted as in-tree after you started using
> LSM ID as an identifier? I don't know how many device drivers have been accepted
> as in-tree, but generally getting LSM modules in-tree is much difficult than
> getting device drivers in-tree. Yet another big barrier!
>
> This problem is new and unique to LSM.

Unfortunately your argument is old and tired.  Tetsuo we've
exhaustively discussed these issues more than once, until there is
something new which warrants a new debate, I'm done discussing this
with you.

-- 
paul-moore.com