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

[Kees Cook <kees@kernel.org>]

On Sat, Dec 21, 2024 at 10:40:45PM +0900, Tetsuo Handa wrote:
> 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.

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/

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

-Kees

-- 
Kees Cook