On Sat, Jul 6, 2024 at 6:40 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Fri, Jul 5, 2024 at 3:34 PM KP Singh <kpsingh@xxxxxxxxxx> wrote: > > On Fri, Jul 5, 2024 at 8:07 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > On Wed, Jul 3, 2024 at 7:08 PM KP Singh <kpsingh@xxxxxxxxxx> 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@xxxxxxxxxxxx/ 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@xxxxxxxxxxxxxx/ > > -- > paul-moore.com
