On Sat, Dec 21, 2024 at 10:40:45PM +0900, Tetsuo Handa wrote:

Hello, Kees.

On 2024/12/21 19:00, Tetsuo Handa wrote:

quoted

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.

Sure!

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.

If the LSM core did a kmem_buckets_create() for each LSM, and the LSMs
were adjusted to explicitly allocate from their own bucket set, that
would be one way. Or just for the LSM as a whole (1 set of buckets
instead of a set for each LSM). I'd be happy to review patches for
either idea.

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

No, I think accuracy for slabinfo is more important.

What do you think?

I think per-site buckets is going to be the most effective long-term:
https://lore.kernel.org/lkml/20240809072532.work.266-kees@kernel.org/ (local)

But that doesn't exclude new kmem_buckets_create() users.

-Kees

-- 
Kees Cook