[PATCH v7 0/5] Reduce overhead of LSMs with static calls

[KP Singh]

On Thu, Nov 2, 2023 at 11:30 AM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
>
> On 2023/11/02 19:01, KP Singh wrote:
> > On Thu, Nov 2, 2023 at 10:42 AM Tetsuo Handa
> > <penguin-kernel at i-love.sakura.ne.jp> wrote:
> >>
> >> I didn't get your response on https://lkml.kernel.org/r/c588ca5d-c343-4ea2-a1f1-4efe67ebb8e3@I-love.SAKURA.ne.jp .
> >>
> >> Do you agree that we cannot replace LKM-based LSMs with eBPF-based access control mechanisms,
> >> and do you admit that this series makes LKM-based LSMs more difficult to use?
> >
> > If you want to do a proper in-tree version of dynamic LSMs. There can
> > be an exported symbol that allocates a dynamic slot and registers LSM
> > hooks to it. This is very doable, but it's not my use case so, I am
> > not going to do it.
> >
> > No it does not make LKM based LSMs difficult to use. I am not ready to
> > have that debate again.  I suggested multiple extensions in my replies
> > which you chose to ignore.
>
> You said
>
>   I think this needs to be discussed if and when we allow LKM based LSMs."
>
> as a response to
>
>   It is Casey's commitment that the LSM infrastructure will not forbid LKM-based LSMs.
>   We will start allowing LKM-based LSMs. But it is not clear how we can make it possible to
>   allow LKM-based LSMs.
>
> , and you suggested combination of static calls (for built-in LSMs) and
> linked list (for LKM-based LSMs).

Tetsuo, this is exactly a technical solution and it works, a very easy
API can be made to enable the LKM based use-case (if the maintainers
agree that they want to enable LKM based LSMs)

I think what you can do is send patches for an API for LKM based LSMs
and have it merged before my series, I will work with the code I have
and make LKM based LSMs work. If this work gets merged, and your
use-case is accepted (I think I can speak for at least Kees [if not
others] too here) we will help you if you get stuck with MAX_LSM_COUNT
or a dual static call and linked list based approach.

>
> So, what is your answer to
>
>   Until I hear the real limitations of using BPF, it's a NAK from me.

The burden of proof is on you. All I can say is that if you wanted to
implement the policy logic you want, you could. If you cannot, please
share specifics and the BPF / LSM community will help.

>
> ? Do you agree to allow dynamically appendable LSM modules?

Nice try, I am for dynamically loadable hook logic, that's why I
implemented the BPF LSM. What you want to ask me is am I for LKM LSMs.
Regarding the LKM based LSMs, it's my opinion that it should be done
with BPF LSM because it's actually safer and does not have the
maintenance overhead that a kernel module has.

My 0.02c, please share code, specifics and if you like your use case,
get it merged with a patch series. From here onwards, I won't be
responding to hypotheticals.

>