Re: [PATCH v2] lsm: check size of writes

Tetsuo Handa
2024-12-21T13:40:55Z

Hello, Kees.

On 2024/12/21 19:00, Tetsuo Handa wrote:
> FYI: I sent
>
> https://lkml.kernel.org/r/014cd694-cc27-4a07-a34a-2ae95d744515@I-love.SAKURA.ne.jp
>
> which makes this patch redundant if my patch is accepted.
>

I got a question regarding commit d73778e4b867 ("mm/util: Use dedicated
slab buckets for memdup_user()").

While I consider that using the same slab buckets for memdup_user() and
memdup_user_nul() is OK, I came to feel that we could utilize
kmem_buckets_create() more aggressively for debug purpose and/or
isolation purpose.

I got three bug reports on TOMOYO
https://lkml.kernel.org/r/67646895.050a0220.1dcc64.0023.GAE@google.com
and I guess that at least the fix for the first bug is
https://lkml.kernel.org/r/20241218185000.17920-2-leocstone@gmail.com
because the syz reproducer includes access to
/sys/kernel/config/nvmet/discovery_nqn interface.

If the slab buckets for nvmet and TOMOYO were separated, we might have
received these bug reports as nvmet bugs rather than TOMOYO bugs.

We switched to use module-local workqueue if that module needs to call
flush_workqueue() because calling flush_workqueue() against the kernel global
workqueues might introduce unpredictable locking dependency. Therefore, I came
to feel that it might be helpful to add a kernel config option for switching
whether to use dedicated slab buckets for individual module/subsystems.

For example, I don't know whether it is worth using a dedicated slab bucket
for each LSM module, but I feel that having a dedicated slab bucket shared
between all LSM modules might be worth doing, in order to reduce possibility
of by error overrunning into chunks used by LSM modules caused by bugs in
unrelated code.

Maybe we want a flag for not to bloat /proc/slabinfo output if we allow
using dedicated slab buckets for individual module/subsystems...

What do you think?