Re: [PATCH v5 2/6] mm/slab: Plumb kmem_buckets into __do_kmalloc_node()
From: Vlastimil Babka <hidden>
Date: 2024-06-20 13:08:34
Also in:
linux-hardening, linux-mm, lkml
On 6/19/24 9:33 PM, Kees Cook wrote:
Introduce CONFIG_SLAB_BUCKETS which provides the infrastructure to support separated kmalloc buckets (in the following kmem_buckets_create() patches and future codetag-based separation). Since this will provide a mitigation for a very common case of exploits, enable it by default.
No longer "enable it by default".
To be able to choose which buckets to allocate from, make the buckets available to the internal kmalloc interfaces by adding them as the first argument, rather than depending on the buckets being chosen from
second argument now
the fixed set of global buckets. Where the bucket is not available, pass NULL, which means "use the default system kmalloc bucket set" (the prior existing behavior), as implemented in kmalloc_slab(). To avoid adding the extra argument when !CONFIG_SLAB_BUCKETS, only the top-level macros and static inlines use the buckets argument (where they are stripped out and compiled out respectively). The actual extern functions can then been built without the argument, and the internals fall back to the global kmalloc buckets unconditionally.
Also describes the previous implementation and not the new one?
quoted hunk ↗ jump to hunk
--- a/mm/Kconfig +++ b/mm/Kconfig@@ -273,6 +273,22 @@ config SLAB_FREELIST_HARDENED sacrifices to harden the kernel slab allocator against common freelist exploit methods. +config SLAB_BUCKETS + bool "Support allocation from separate kmalloc buckets" + depends on !SLUB_TINY + help + Kernel heap attacks frequently depend on being able to create + specifically-sized allocations with user-controlled contents + that will be allocated into the same kmalloc bucket as a + target object. To avoid sharing these allocation buckets, + provide an explicitly separated set of buckets to be used for + user-controlled allocations. This may very slightly increase + memory fragmentation, though in practice it's only a handful + of extra pages since the bulk of user-controlled allocations + are relatively long-lived. + + If unsure, say Y.
I was wondering why I don't see the buckets in slabinfo and turns out it was SLAB_MERGE_DEFAULT. It would probably make sense for SLAB_MERGE_DEFAULT to depends on !SLAB_BUCKETS now as the merging defeats the purpose, wdyt?