Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230710082500.1838896-1-lsahn@wewakecorp.com>
 <CAHC9VhQY0Uq_xQ_AwAuZ8gJbS52nQvRONHvCxiR-dGDg3BviRw@mail.gmail.com> <0fcac6a8-4ab8-91bc-34e0-cbbb81da3973@schaufler-ca.com>
In-Reply-To: <0fcac6a8-4ab8-91bc-34e0-cbbb81da3973@schaufler-ca.com>
From:   Paul Moore <paul@paul-moore.com>
Date:   Mon, 17 Jul 2023 16:50:40 -0400
Message-ID: <CAHC9VhQ3nmpRQPT6m2jBKtpML0sR9htARWr2cTPt78s=4nRkcg@mail.gmail.com>
Subject: Re: [PATCH] selinux: optimize major part with a kernel config in selinux_mmap_addr()
To:     Casey Schaufler <casey@schaufler-ca.com>
Cc:     Leesoo Ahn <lsahn@ooseel.net>, lsahn@wewakecorp.com,
        Stephen Smalley <stephen.smalley.work@gmail.com>,
        Eric Paris <eparis@parisplace.org>, selinux@vger.kernel.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, Jul 17, 2023 at 4:31=E2=80=AFPM Casey Schaufler <casey@schaufler-ca=
.com> wrote:
> On 7/17/2023 1:13 PM, Paul Moore wrote:
> > On Mon, Jul 10, 2023 at 4:25=E2=80=AFAM Leesoo Ahn <lsahn@ooseel.net> w=
rote:
> >> The major part, the conditional branch in selinux_mmap_addr() is alway=
s to be
> >> false so long as CONFIG_LSM_MMAP_MIN_ADDR is set to zero at compile ti=
me.
> >>
> >> This usually happens in some linux distros, for instance Ubuntu, which
> >> the config is set to zero in release version. Therefore it could be a =
bit
> >> optimized with '#if <expr>' at compile time.
> >>
> >> Signed-off-by: Leesoo Ahn <lsahn@wewakecorp.com>
> >> ---
> >>  security/selinux/hooks.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> > First, I agree with Stephen's comments that you should ask your distro
> > (you mentioned Debian) to move MIN_ADDR higher.  Beyond that, I have
> > one request, see below ...
> >
> >> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> >> index d06e350fedee..a049aab6524b 100644
> >> --- a/security/selinux/hooks.c
> >> +++ b/security/selinux/hooks.c
> >> @@ -3723,11 +3723,13 @@ static int selinux_mmap_addr(unsigned long add=
r)
> >>  {
> >>         int rc =3D 0;
> >>
> >> +#if CONFIG_LSM_MMAP_MIN_ADDR > 0
> >>         if (addr < CONFIG_LSM_MMAP_MIN_ADDR) {
> >>                 u32 sid =3D current_sid();
> >>                 rc =3D avc_has_perm(sid, sid, SECCLASS_MEMPROTECT,
> >>                                   MEMPROTECT__MMAP_ZERO, NULL);
> >>         }
> >> +#endif
> >>
> >>         return rc;
> >>  }
> > Pre-processor conditionals inside a function are generally something
> > we don't recommend.  In this case I would suggest doing something like
> > this:
> >
> > #if (MMAP_MIN_ADDR > 0)
> > static int selinux_mmap_addr(...)
> > {
> >   /* current func definition */
> > }
> > #else /* MMAP_MIN_ADDR > 0 */
> > static int selinux_mmap_addr(...)
> > {
> >   return 0;
> > }
> > #endif /* MMAP_MIN_ADDR > 0 */
>
> Better yet, skip the #else here and #if out the LSM_HOOK_INIT(mmap_addr, =
...).
> No hook at all is faster than a hook that does nothing.

My only concern with that approach is the disconnected nature: one
ifdef around the func definition, one around the LSM_HOOK_INIT() call.
If we thought a zero MMAP_MIN_ADDR value was a good idea, or even
common, I would be more inclined to pay the bad-code-practices-tax
here, but seeing as we don't want to encourage a zero MMAP_MIN_ADDR
value I'd rather lean towards the more maintainable code.

--=20
paul-moore.com