From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8278723A984; Tue, 12 May 2026 04:57:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778561824; cv=none; b=nRl1h45J58lfxoc77JwAyA6H13uejlyeKhhVGSF5+op00j5SKnQEyvocx7WofOjkYZ9LviZDh2TSu8p/kpsLMHw9ozWEjUBL6aeBqg2KdTESY4SXE5YsvT3oRtlQHXjCGraKyeHg73feY6r/mCTFTKRGu3C67X3gTX+wXgrC0Hs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778561824; c=relaxed/simple; bh=SuGzOrO8Ty44mf2D4njc9ML+1sXJQc1sV4S69Dg22ww=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oeH+3kMDkgpAlGRCgN6qnFuE9mqFhr+NGcJkJLR720KowMPFxdo4D1MiGY1eVZ6jbCzd/mtoldINnIvMJCuiKLUwOOk0LQgXsDnN+2f2/IfPxYr4xa4sdH25Sc9HDnIKs0UgiN6j/yAHEDj5YYQEtiALeMii3qJuao5ndqLtvvg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IdzDA37+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IdzDA37+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0372C2BCB0; Tue, 12 May 2026 04:57:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778561824; bh=SuGzOrO8Ty44mf2D4njc9ML+1sXJQc1sV4S69Dg22ww=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IdzDA37+6qHy5RsQcN2ylceO9txldaqjFLIXbOjt3qcpLZNB/CuSElDOLf3phdqFa iEgyQxtJYvEFVh2PKNQEp3TjPI/ojxsvZLeGUEwUq+3Z7wCs9FTEvI64yTlqwZIckG BdWcHutsJ3yczyQTuOl0GZLAxnO4qMu87n99WtTBuIae7Ic/hLzEEnV9HKYp+T2slA uddxc0GNuuKFm4lachuclzP+dxeakxHuxvocO0QKxEitVZdMPVFhBirzMfnCBlAhK4 LP6qFbG/BTcGzyke3nu1xgOrC2zd0dSKaM5s/oSmOgi9KCz8Brt2j6+JkKRib901X7 4o0UmmthTuQ0A== Date: Tue, 12 May 2026 13:57:01 +0900 From: "Harry Yoo (Oracle)" To: Marco Elver Cc: Vlastimil Babka , Andrew Morton , "Gustavo A. R. Silva" , "Liam R. Howlett" , Andrey Konovalov , Bill Wendling , David Hildenbrand , David Rientjes , Dmitry Vyukov , Jann Horn , Justin Stitt , KP Singh , Kees Cook , Lorenzo Stoakes , Matteo Rizzo , Michal Hocko , Mike Rapoport , Nathan Chancellor , Nick Desaulniers , Roman Gushchin , Suren Baghdasaryan , linux-hardening@vger.kernel.org, Nicolas Schier , Dennis Zhou , Tejun Heo , Christoph Lameter , Hao Li , "Liam R. Howlett" , Alexander Potapenko , Miguel Ojeda , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kasan-dev@googlegroups.com, llvm@lists.linux.dev, GONG Ruiqi Subject: Re: [PATCH v4 1/3] slab: support for compiler-assisted type-based slab cache partitioning Message-ID: References: <20260511200136.3201646-1-elver@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260511200136.3201646-1-elver@google.com> On Mon, May 11, 2026 at 10:00:48PM +0200, Marco Elver wrote: > Rework the general infrastructure around RANDOM_KMALLOC_CACHES into more > flexible KMALLOC_PARTITION_CACHES, with the former being a partitioning > mode of the latter. > > Introduce a new mode, KMALLOC_PARTITION_TYPED, which leverages a feature > available in Clang 22 and later, called "allocation tokens" via > __builtin_infer_alloc_token() [1]. Unlike KMALLOC_PARTITION_RANDOM > (formerly RANDOM_KMALLOC_CACHES), this mode deterministically assigns a > slab cache to an allocation of type T, regardless of allocation site. > > The builtin __builtin_infer_alloc_token(, ...) instructs > the compiler to infer an allocation type from arguments commonly passed > to memory-allocating functions and returns a type-derived token ID. The > implementation passes kmalloc-args to the builtin: the compiler performs > best-effort type inference, and then recognizes common patterns such as > `kmalloc(sizeof(T), ...)`, `kmalloc(sizeof(T) * n, ...)`, but also > `(T *)kmalloc(...)`. Where the compiler fails to infer a type the > fallback token (default: 0) is chosen. > > Note: kmalloc_obj(..) APIs fix the pattern how size and result type are > expressed, and therefore ensures there's not much drift in which > patterns the compiler needs to recognize. Specifically, kmalloc_obj() > and friends expand to `(TYPE *)KMALLOC(__obj_size, GFP)`, which the > compiler recognizes via the cast to TYPE*. > > Clang's default token ID calculation is described as [1]: > > typehashpointersplit: This mode assigns a token ID based on the hash > of the allocated type's name, where the top half ID-space is reserved > for types that contain pointers and the bottom half for types that do > not contain pointers. > > Separating pointer-containing objects from pointerless objects and data > allocations can help mitigate certain classes of memory corruption > exploits [2]: attackers who gains a buffer overflow on a primitive > buffer cannot use it to directly corrupt pointers or other critical > metadata in an object residing in a different, isolated heap region. > > It is important to note that heap isolation strategies offer a > best-effort approach, and do not provide a 100% security guarantee, > albeit achievable at relatively low performance cost. Note that this > also does not prevent cross-cache attacks: while waiting for future > features like SLAB_VIRTUAL [3] to provide physical page isolation, this > feature should be deployed alongside SHUFFLE_PAGE_ALLOCATOR and > init_on_free=1 to mitigate cross-cache attacks and page-reuse attacks as > much as possible today. > > With all that, my kernel (x86 defconfig) shows me a histogram of slab > cache object distribution per /proc/slabinfo (after boot): > > > kmalloc-part-15 1465 ++++++++++++++ > kmalloc-part-14 2988 +++++++++++++++++++++++++++++ > kmalloc-part-13 1656 ++++++++++++++++ > kmalloc-part-12 1045 ++++++++++ > kmalloc-part-11 1697 ++++++++++++++++ > kmalloc-part-10 1489 ++++++++++++++ > kmalloc-part-09 965 +++++++++ > kmalloc-part-08 710 +++++++ > kmalloc-part-07 100 + > kmalloc-part-06 217 ++ > kmalloc-part-05 105 + > kmalloc-part-04 4047 ++++++++++++++++++++++++++++++++++++++++ > kmalloc-part-03 183 + > kmalloc-part-02 283 ++ > kmalloc-part-01 316 +++ > kmalloc 1422 ++++++++++++++ > > The above /proc/slabinfo snapshot shows me there are 6673 allocated > objects (slabs 00 - 07) that the compiler claims contain no pointers or > it was unable to infer the type of, and 12015 objects that contain > pointers (slabs 08 - 15). On a whole, this looks relatively sane. > > Additionally, when I compile my kernel with -Rpass=alloc-token, which > provides diagnostics where (after dead-code elimination) type inference > failed, I see 186 allocation sites where the compiler failed to identify > a type (down from 966 when I sent the RFC [4]). Some initial review > confirms these are mostly variable sized buffers, but also include > structs with trailing flexible length arrays. > > Link: https://clang.llvm.org/docs/AllocToken.html [1] > Link: https://blog.dfsec.com/ios/2025/05/30/blasting-past-ios-18/ [2] > Link: https://lwn.net/Articles/944647/ [3] > Link: https://lore.kernel.org/all/20250825154505.1558444-1-elver@google.com/ [4] > Link: https://discourse.llvm.org/t/rfc-a-framework-for-allocator-partitioning-hints/87434 > Acked-by: GONG Ruiqi > Co-developed-by: Harry Yoo (Oracle) > Signed-off-by: Harry Yoo (Oracle) > Signed-off-by: Marco Elver > --- Looks good to me, Reviewed-by: Harry Yoo (Oracle) > # Sanity check userspace page table mappings. > CONFIG_PAGE_TABLE_CHECK=y > +config RANDOM_KMALLOC_CACHES > + bool > + transitional > + help > + Transitional config for migration to KMALLOC_PARTITION_CACHES. Heh, didn't realize transitional config was a thing, nice! -- Cheers, Harry / Hyeonggon