Moved module init-functions into the module.

This commit moves the call to initialize the LSM modules inline into the LSM-files themselves.

This removes the need to hunt around for the setup, which was something that bit me when I wrote my own (unrelated) LSM.

Keeping LSM code in one place, including the setup of the hooks seems like a sane choice.

This patch has been updated to use security_init, as per feedback from Ethan Zhao. This should ensure that the LSM init is called "early".

Signed-off-by Steve Kemp <[email protected]>

---
 include/linux/lsm_hooks.h  | 10 ----------
 security/loadpin/loadpin.c |  5 ++++-
 security/security.c        |  2 --
 security/yama/yama_lsm.c   |  5 ++++-
 4 files changed, 8 insertions(+), 14 deletions(-)

include/linux/lsm_hooks.h +0 -10

index 080f34e..a6dbdc7 100644
@@ -1936,15 +1936,5 @@ static inline void security_delete_hooks(struct security_hook_list *hooks,
 
 extern int __init security_module_enable(const char *module);
 extern void __init capability_add_hooks(void);
-#ifdef CONFIG_SECURITY_YAMA
-extern void __init yama_add_hooks(void);
-#else
-static inline void __init yama_add_hooks(void) { }
-#endif
-#ifdef CONFIG_SECURITY_LOADPIN
-void __init loadpin_add_hooks(void);
-#else
-static inline void loadpin_add_hooks(void) { };
-#endif
 
 #endif /* ! __LINUX_LSM_HOOKS_H */

security/loadpin/loadpin.c +4 -1

index dbe6efd..127eb5ca 100644
@@ -179,12 +179,15 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
 	LSM_HOOK_INIT(kernel_read_file, loadpin_read_file),
 };
 
-void __init loadpin_add_hooks(void)
+static int __init loadpin_add_hooks(void)
 {
 	pr_info("ready to pin (currently %sabled)", enabled ? "en" : "dis");
 	security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
+	return 0;
 }
 
+security_initcall(loadpin_add_hooks);
+
 /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
 module_param(enabled, int, 0);
 MODULE_PARM_DESC(enabled, "Pin module/firmware loading (default: true)");

security/security.c +0 -2

index b9fea39..110b85b 100644
@@ -67,8 +67,6 @@ int __init security_init(void)
 	 * Load minor LSMs, with the capability module always first.
 	 */
 	capability_add_hooks();
-	yama_add_hooks();
-	loadpin_add_hooks();
 
 	/*
 	 * Load all the remaining security modules.

security/yama/yama_lsm.c +0 -0

index 8298e09..e3c1d10 100644
@@ -482,9 +482,12 @@ static void __init yama_init_sysctl(void)
 static inline void yama_init_sysctl(void) { }
 #endif /* CONFIG_SYSCTL */
 

Quoted 8 lines · Steve Kemp

This commit moves the call to initialize the LSM modules inline into the LSM-files themselves.

This removes the need to hunt around for the setup, which was something that bit me when I wrote my own (unrelated) LSM.

Keeping LSM code in one place, including the setup of the hooks seems like a sane choice.

The module initialization code belongs in the module. The LSM infrastructure should have an absolute minimum of module specific information. I would rather see the "minor" modules (yama, loadpin) changed to use the module registration scheme used by the "major" modules, but that will require a mechanism to ensure module ordering, and we don't have that yet. No, don't do this.

Quoted 7 lines

The module initialization code belongs in the module. The LSM infrastructure should have an absolute minimum of module specific information. I would rather see the "minor" modules (yama, loadpin) changed to use the module registration scheme used by the "major" modules, but that will require a mechanism to ensure module ordering, and we don't have that yet. No, don't do this.

Yeah, I agree: initialization order is important here and I don't want to depend on the Makefile for this.