On Mon, 6 Apr 2026 at 06:28, 'Harry Yoo (Oracle)' via kasan-dev <[email protected]> wrote: > On Fri, Apr 03, 2026 at 08:29:22PM +0200, Vlastimil Babka (SUSE) wrote: > > On 4/3/26 08:27, Harry Yoo (Oracle) wrote: > > >> diff --git a/include/linux/slab.h b/include/linux/slab.h > > >> index 15a60b501b95..c0bf00ee6025 100644 > > >> --- a/include/linux/slab.h > > >> +++ b/include/linux/slab.h > > >> @@ -864,10 +877,10 @@ unsigned int kmem_cache_sheaf_size(struct > > >> slab_sheaf *sheaf); > > >> * with the exception of kunit tests > > >> */ > > >> > > >> -void *__kmalloc_noprof(size_t size, gfp_t flags) > > >> +void *__kmalloc_noprof(size_t size, gfp_t flags, kmalloc_token_t token) > > >> __assume_kmalloc_alignment __alloc_size(1); > > >> > > >> -void *__kmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), gfp_t flags, > > >> int node) > > >> +void *__kmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), gfp_t flags, > > >> int node, kmalloc_token_t token) > > >> __assume_kmalloc_alignment __alloc_size(1); > > > > > > So the @token parameter is unused when CONFIG_PARTITION_KMALLOC_CACHES is > > > disabled but still increases the kernel size by a few kilobytes... > > > but yeah I'm not sure if we can get avoid it without hurting readability. > > > > > > Just saying. (does anybody care?) > > > > Well we did care enough with CONFIG_SLAB_BUCKETS to hide the unused param > > using DECL_BUCKET_PARAMS(), > > Hmm yeah. > > I wasn't sure if we could do this without hurting readability, > but perhaps we could... > > > so maybe extend that idea? > > I think it's not just kernel size, but increased register pressure etc.
I'll take a closer look at generated code. In some cases the compiler ought to omit zero-sized arguments, so I want to be sure we're not prematurely optimizing and the size increase is not some other effect. > Something like this should work? (diff on top of this patch) Thanks, I'll consider it. Re your other comments: > Assuming not all people building the kernel are security experts... > (including myself) could you please add some insights/guidance on how to > decide between RANDOM_KMALLOC_CACHES and TYPED_KMALLOC_CACHES? You can find different arguments for either, and in the original RFC that was part of the discussion. However, my biased view is that type-based partitioning in general is the stronger security boundary. Because it creates a deterministic separation; specifically isolating pointer-containing objects from pointerless ones: it effectively kills certain classes of exploit techniques that probabilistic defenses (like randomization) only delay, especially in environments where attackers can retry or use side-channels. The current pointer/non-pointer scheme is relatively intuitive with well-understood properties, and a good start. However, an open research question is if better alloc-token ID schemes exist: one that is tailored to kernel data structures that would meaningfully increase exploitation difficulty further without increasing the number of partitions. Since an improved scheme could simply be activated with a compiler flag, having the baseline infrastructure available and maintained is the first step. > Now somewhat out-of-scope (or at least pre-existing) review comments > from Sashiko that I think are still worth mentioning... Indeed, these are pre-existing issues with RANDOM_KMALLOC_CACHES. Worth follow-up patches, but this patch here wants to just get the TYPED_KMALLOC_CACHES infrastructure in place so we can build on top of it. Thanks, -- Marco
