On 2025/05/03 5:01, Paul Moore wrote:

## Removing LSM Hooks

If a LSM hook is no longer used by any in-kernel LSMs, there is no ongoing work
in progress involving the hook, and no expectation of future work that will use
the hook, the LSM community may consider removal of the LSM hook.  The decision
to ultimately remove the LSM hook should balance ongoing maintenance and
performance concerns with the social challenges of reintroducing the hook if
it is needed at a later date.

What about BPF-based LSM users? Since BPF-based LSMs cannot be in-kernel LSMs,
it will be difficult for users of BPF-based LSMs to respond (that someone wants
some to-be-removed LSM hook) when removal of an LSM hook is proposed.

## Removing LSMs

If a LSM has not been actively maintained for a period of time such that it is
becoming a maintenance burden for other developers, or there are serious
concerns about the LSM's ability to deliver on its stated purpose, the LSM
community may consider deprecating and ultimately removing the LSM from the
Linux kernel.  However, before considering deprecation, the LSM community
should make every reasonable effort to find a suitable maintainer for the LSM
while also surveying the major Linux distributions to better understand the
impact a deprecation would have on the downstream distro/user experience.  If
deprecation remains the only viable option, the following process should be
used as a starting point for deprecating the LSM:

What about users using the major Linux distributions whose kernel's major version
won't change frequently (e.g. some enterprise distro has 10 years of lifetime, and
would require 3 or 4 years when updating such distro's major version) ? Such users
likely fail to know that deprecation process is in progress, and likely suddenly
be notified of removal of LSMs one day. I agree that the upstream kernel may need
to remove no longer maintained LSMs, but it will be hard to make an assumption that
any reasonable user has already seen the deprecation messages.