[PATCH v13 3/5] security: Replace indirect LSM hook calls with static calls

[KP Singh]

On Sat, Jul 6, 2024 at 6:40 AM Paul Moore <paul at paul-moore.com> wrote:
>
> On Fri, Jul 5, 2024 at 3:34 PM KP Singh <kpsingh at kernel.org> wrote:
> > On Fri, Jul 5, 2024 at 8:07 PM Paul Moore <paul at paul-moore.com> wrote:
> > > On Wed, Jul 3, 2024 at 7:08 PM KP Singh <kpsingh at kernel.org> wrote:

[...]

> >
> > Paul, I am talking about eliminating a class of bugs, but you don't
> > seem to get the point and you are fixated on the very instance of this
> > bug class.
>
> I do understand that you are trying to eliminate a class of bugs, the
> point I'm trying to make is that I believe we have addressed that
> already with the patches I've previously cited.

The class I am referring to is useless hooks returning a default value
and imposing a denial / enforcement when they are not supposed to. If
you think this class of issues is not relevant to the overall LSM,
sure. I would still like BPF LSM to not add default callbacks as I
have always maintained since day 1:

https://lwn.net/ml/linux-kernel/20200224171305.GA21886@chromium.org/

BPF LSM does not want to provide a default decision until a BPF LSM
policy program is loaded,

>
> > > > 2. Performance, no extra function call.
> > >
> > > Convince me the bug still exists first and then we can discuss the
> > > merits of whatever solutions are proposed.
> >
> > This is independent of the bug!
>
> Correctness first, maintainability second, performance third.  That's
> my current priority and I feel the maintainability hit doesn't justify
> the performance win at this point in time.  Besides, we're already
> expecting a big performance boost simply by moving to static_calls.
>
> > As I said, If you don't want to modify the core LSM layer, it's okay,
> > I still want to go with changes local to the BPF LSM, If you really
> > don't agree with the changes local to the BPF LSM, we can have it go
> > via the BPF tree and seek Linus' help to resolve the conflict.
>
> As the BPF maintainer you are always free to do whatever you like
> within the scope of the LSM you maintain so long as it does not touch
> or otherwise impact any of the other LSMs or the LSM framework.  If
> you do affect the other LSMs, or the LSM framework, you need to get an
> ACK from the associated maintainer.  That's pretty much how Linux
> kernel development works.

Okay, then let's not make an LSM API, I will handle it within the BPF LSM.

The patch I proposed should not affect any other LSMs and is self
contained within BPF LSM:

https://lore.kernel.org/bpf/CACYkzJ6jADoGNuPP3-1wkk-kV7NOQh+eFkU5KEDEZgq9qNNEfg@mail.gmail.com/


>
> --
> paul-moore.com