Kees Cook wrote:

On Wed, Mar 22, 2017 at 3:46 AM, Tetsuo Handa
[off-list ref] wrote:

quoted

We might introduce different "struct security_hook_heads" for built-in
LSM modules and dynamically loadable LSM modules when we start allowing
dynamically loadable LSM modules. But even if we decide to use different
lists, there is no need to export "struct security_hook_heads" for
dynamically loadable LSM modules and define different LSM_HOOK_INIT() for
built-in LSM modules and dynamically loadable LSM modules only for
switching list_head's address. Let's use index number within
"struct security_hook_heads" so that we can switch list_head's address
inside the registration function.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Kees Cook <redacted>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Stephen Smalley <redacted>
Cc: Casey Schaufler <casey@schaufler-ca.com>
Cc: James Morris <redacted>

While somewhat in line with my suggestion about enum, this loses us
compile-time bounds checking on the offset (i.e. idx here could be
outside the list_heads). I'd want this bounds checked first.

Isn't suspecting .idx equivalent to suspecting .head which is currently not suspected? ;-)

But no problem. It is not a costly thing.

-		list_add_tail_rcu(&hooks[i].list, &list[hooks[i].idx]);
+		unsigned int idx = hooks[i].idx;
+		if (idx < sizeof(struct security_hook_heads) / sizeof(struct list_head))
+			list_add_tail_rcu(&hooks[i].list, &list[idx]);

However, I'm not starting to remember that perhaps the reason an enum
wasn't used was to gain type checking on the hook function
assignments? My memory is fuzzy...

Right.

-Kees

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html