Re: [PATCH v13 4/5] security: Update non standard hooks to use static calls

Paul Moore
2024-07-09T19:05:43Z

On Tue, Jul 9, 2024 at 12:53 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 7/9/2024 5:36 AM, KP Singh wrote:
> > [...]
> >
> >>> --- a/security/security.c
> >>> +++ b/security/security.c
> >>> @@ -948,10 +948,48 @@ out: \
> >>> RC; \
> >>> })
> >>>
> >>> -#define lsm_for_each_hook(scall, NAME) \
> >>> - for (scall = static_calls_table.NAME; \
> >>> - scall - static_calls_table.NAME < MAX_LSM_COUNT; scall++) \
> >>> - if (static_key_enabled(&scall->active->key))
> >>> +/*
> >>> + * Can be used in the context passed to lsm_for_each_hook to get the lsmid of the
> >>> + * current hook
> >>> + */
> >>> +#define current_lsmid() _hook_lsmid
> >> See my comments below about security_getselfattr(), I think we can drop
> >> the current_lsmid() macro. If we really must keep it, we need to rename
> >> it to something else as it clashes too much with the other current_XXX()
> >> macros/functions which are useful outside of our wacky macros.
> > call_hook_with_lsmid is a pattern used by quite a few hooks, happy to
> > update the name.
> >
> > What do you think about __security_hook_lsm_id().
>
> I really dislike it. The security prefix (even with __) tells the
> developer in security.c that the code is used elsewhere. How about
> lsm_hook_current_id()?

See my reply. There is enough ugliness in converting the hooks in
this particular patch that I think we need to shelve this patch too.

--
paul-moore.com