On Tue, Jul 9, 2024 at 12:53 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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
