From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 4E527369D4D; Tue, 19 May 2026 23:57:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779235072; cv=none; b=o4zrK0C7sZizZkL5W/cb21P/4YQ1laVNTSPUddmA+AiMMpGCYlnPCwBpV9f0iISOv6kz+R5pnwRZjJKMYnhN5CRUdpc3QAEcH6EV8AwoE29eiv5lMT9V2+ON/0CdMgX/1lgN0owLnMSJhHiGKH21HyzG3KcYu9N9ipqVCCHb7RQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779235072; c=relaxed/simple; bh=7UTzWNyq8e8HIpKZw64gKTF6fVCOvbLqoh4DSh8fbSI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bYKIrV7rrxYGf59Ax3jPAjqLmLFZSIVQ+m8Zfo+ahunX4Cet/zR+npogF2b4cUNeeFSa4BIdVaH7C8egIBQ6Hl69mqvJuSFVOyAjn9/+Zva0OEsuDHUYvaD4Z2CWhqTbP6yk6dc8UiyNxP0rFSFzfVIk7zN4S8HIotnrTfuTaiQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j+IawRDC; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j+IawRDC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 328051F00893; Tue, 19 May 2026 23:57:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779235071; bh=dbsOAfuN8ml++VqHBD2xHu4Tk0pEHTjebmx81mRjNjQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=j+IawRDC4po5J/sySD3Vspo/j2V6R7CsxVFwZtizeYW8pdH/UsliZI/qQZreqa8ll +9cK0dwngXE+55CkwGhFbim4x6YdUttO7nM04lyrmgGpKcD3RtBQwuzb1y64Trj6fZ VVWfqd7g3nHCG/zZRm/8qqKykiislzCZKL89CzHEyWbFGc0fUOcjHiohFpRNELU0AR ejYF/V59JUUqr7nmzQMRIJBisCdJ9anllfnXNzmrBu2lUTqvJMepXGcCu9AdyWCc36 5Bjrs4QZ8Ac5swPr9Ow3Z/mDI5sHraIw+5YwUah4DOCvHh2DIw53nFgb5ThnZo5I5q 2RyBf6pHU8qAA== Message-ID: Date: Wed, 20 May 2026 08:57:42 +0900 Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/3] slab: support for compiler-assisted type-based slab cache partitioning To: Marco Elver , Pedro Falcato 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 References: <20260511200136.3201646-1-elver@google.com> Content-Language: en-US From: Harry Yoo In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/18/26 11:08 PM, Marco Elver wrote: > On Fri, 15 May 2026 at 16:28, Pedro Falcato wrote: >> >> 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 ++++++++++++++ >> >> Hi, >> >> A couple of questions (I apologise if this was asked before, I wasn't involved >> in this thread): >> >> 1) What's the object behind kmalloc-part-04? I imagine it's a single type >> getting allocated a lot? > > That's from __kmemdup_nul(). __kmemdup_nul() is probably a good fit for SLAB_BUCKETS? -- Cheers, Harry / Hyeonggon