linux-hardening - Re: [PATCH RFC] slab: support for compiler-assisted type-based slab cache partitioning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <97dca868-dc8a-422a-aa47-ce2bb739e640@huawei.com>
Date: Tue, 26 Aug 2025 12:59:17 +0800
From: GONG Ruiqi <gongruiqi1@...wei.com>
To: Marco Elver <elver@...gle.com>
CC: <linux-kernel@...r.kernel.org>, <kasan-dev@...glegroups.com>, "Gustavo A.
 R. Silva" <gustavoars@...nel.org>, "Liam R. Howlett"
	<Liam.Howlett@...cle.com>, Alexander Potapenko <glider@...gle.com>, Andrew
 Morton <akpm@...ux-foundation.org>, Andrey Konovalov <andreyknvl@...il.com>,
	David Hildenbrand <david@...hat.com>, David Rientjes <rientjes@...gle.com>,
	Dmitry Vyukov <dvyukov@...gle.com>, Florent Revest <revest@...gle.com>, Harry
 Yoo <harry.yoo@...cle.com>, Jann Horn <jannh@...gle.com>, Kees Cook
	<kees@...nel.org>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Matteo Rizzo
	<matteorizzo@...gle.com>, Michal Hocko <mhocko@...e.com>, Mike Rapoport
	<rppt@...nel.org>, Nathan Chancellor <nathan@...nel.org>, Roman Gushchin
	<roman.gushchin@...ux.dev>, Suren Baghdasaryan <surenb@...gle.com>, Vlastimil
 Babka <vbabka@...e.cz>, <linux-hardening@...r.kernel.org>,
	<linux-mm@...ck.org>
Subject: Re: [PATCH RFC] slab: support for compiler-assisted type-based slab
 cache partitioning


On 8/25/2025 11:44 PM, Marco Elver wrote:
> ...
> 
> Introduce a new mode, TYPED_KMALLOC_CACHES, which leverages Clang's
> "allocation tokens" via __builtin_alloc_token_infer [1].
> 
> This mechanism allows the compiler to pass a token ID derived from the
> allocation's type to the allocator. The compiler performs best-effort
> type inference, and recognizes idioms such as kmalloc(sizeof(T), ...).
> Unlike RANDOM_KMALLOC_CACHES, this mode deterministically assigns a slab
> cache to an allocation of type T, regardless of allocation site.
> 
> 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.
> 

Is a type's token id always the same across different builds? Or somehow
predictable? If so, the attacker could probably find out all types that
end up with the same id, and use some of them to exploit the buggy one.

-Ruiqi