[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jLn6c=mr5VC=fUP4LUD18EuPAYyDkYTrv_rpxSuxAz--A@mail.gmail.com>
Date: Sat, 31 Mar 2018 07:38:54 -0700
From: Kees Cook <keescook@...omium.org>
To: Sargun Dhillon <sargun@...gun.me>
Cc: Casey Schaufler <casey@...aufler-ca.com>,
LSM <linux-security-module@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Igor Stoppa <igor.stoppa@...wei.com>,
James Morris <jmorris@...ei.org>,
Stephen Smalley <sds@...ho.nsa.gov>,
Paul Moore <paul@...l-moore.com>, plautrba@...hat.com
Subject: Re: [PATCH v3 1/1] security: Add mechanism to safely (un)load LSMs
after boot time
On Fri, Mar 30, 2018 at 11:16 PM, Sargun Dhillon <sargun@...gun.me> wrote:
> On Fri, Mar 30, 2018 at 2:39 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>> static struct security_hook_list null_hooks[SECURITY_HOOK_COUNT];
>>> -#define HAS_FUNC(SHL, FUNC) (SHL->hook.FUNC)
>>> +DEFINE_STATIC_SRCU(security_hook_srcu);
>>> +
>>> +static inline bool is_null_hook(struct security_hook_list *shl)
>>> +{
>>> + union {
>>> + void *cb_ptr;
>>> + union security_list_options slo;
>>> + } hook_options;
>>> +
>>> + hook_options.slo = shl->hook;
>>> + return !hook_options.cb_ptr;
>>> +}
>>
>> I like the HAS_FUNC() approach better.
>
> Just curious, why? I personally prefer small static inline functions
> over macros, if possible.
Generally speaking, small static inline functions are better since
they provide type-checking. In this case, though, it looks like you're
just doing a cast, but with a union. Why isn't this just:
return !!((uintptr_t)shl->hook)
?
Though the security_list_options union exists for callback type
checking, so really, having HAS_FUNC() with the explicit function
you're interested in creates a bit of self-documenting code (even if
it always resolves to the above test).
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists