On Sat, Jul 6, 2024 at 6:40 AM Paul Moore [off-list ref] wrote:

On Fri, Jul 5, 2024 at 3:34 PM KP Singh [off-list ref] wrote:

quoted

On Fri, Jul 5, 2024 at 8:07 PM Paul Moore [off-list ref] wrote:

quoted

On Wed, Jul 3, 2024 at 7:08 PM KP Singh [off-list ref] wrote:

[...]

quoted

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,

quoted

quoted

quoted

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.

quoted

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/ (local)

--
paul-moore.com