[RFC PATCH 27/29] lsm: consolidate all of the LSM framework initcalls
Paul Moore
paul at paul-moore.com
Fri Apr 11 01:21:46 UTC 2025
On Wed, Apr 9, 2025 at 7:52 PM Kees Cook <kees at kernel.org> wrote:
> On Wed, Apr 09, 2025 at 02:50:12PM -0400, Paul Moore wrote:
> > The LSM framework itself registers a small number of initcalls, this
> > patch converts these initcalls into the new initcall mechanism.
> >
> > Signed-off-by: Paul Moore <paul at paul-moore.com>
> > ---
> > security/inode.c | 3 +--
> > security/lsm.h | 4 ++++
> > security/lsm_init.c | 14 ++++++++++++--
> > security/min_addr.c | 5 +++--
> > 4 files changed, 20 insertions(+), 6 deletions(-)
...
> > @@ -503,7 +508,12 @@ early_initcall(security_initcall_early);
> > */
> > static int __init security_initcall_core(void)
> > {
> > - return lsm_initcall(core);
> > + int rc_sfs, rc_lsm;
> > +
> > + rc_sfs = securityfs_init();
> > + rc_lsm = lsm_initcall(core);
> > +
> > + return (rc_sfs ? rc_sfs : rc_lsm);
> > }
> > core_initcall(security_initcall_core);
>
> Hrm. Given these aren't really _lsm_ hooks, maybe just leave this out. I
> worry about confusing the lsm inits with the lsm subsystem's core inits.
I'm not too concerned about that, and I do prefer it this way.
> Or we need a new stacking type for "required"? But that seems ... heavy.
So I understand the motivation behind that, but that's a big hard "no"
from me at this point in time ;)
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list