Message-ID: <CALGbS4U6fox7SwmdHfDuawmOWfQeQsxtA1X_VqRxTHpSs-sBYw@mail.gmail.com>
Date: Tue, 26 Aug 2025 13:31:54 +0200
From: Florent Revest <revest@...gle.com>
To: Marco Elver <elver@...gle.com>
Cc: GONG Ruiqi <gongruiqi1@...wei.com>, 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>, 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 Tue, Aug 26, 2025 at 1:01 PM Marco Elver <elver@...gle.com> wrote:
>
> On Tue, 26 Aug 2025 at 06:59, GONG Ruiqi <gongruiqi1@...wei.com> wrote:
> > 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.
>
> Yes, it's meant to be deterministic and predictable. I guess this is
> the same question regarding randomness, for which it's unclear if it
> strengthens or weakens the mitigation. As I wrote elsewhere:
>
> > Irrespective of the top/bottom split, one of the key properties to
> > retain is that allocations of type T are predictably assigned a slab
> > cache. This means that even if a pointer-containing object of type T
> > is vulnerable, yet the pointer within T is useless for exploitation,
> > the difficulty of getting to a sensitive object S is still increased
> > by the fact that S is unlikely to be co-located. If we were to
> > introduce more randomness, we increase the probability that S will be
> > co-located with T, which is counter-intuitive to me.
>
> I think we can reason either way, and I grant you this is rather ambiguous.
>
> But the definitive point that was made to me from various security
> researchers that inspired this technique is that the most useful thing
> we can do is separate pointer-containing objects from
> non-pointer-containing objects (in absence of slab per type, which is
> likely too costly in the common case).

One more perspective on this: in a data center environment, attackers
typically get a first foothold by compromising a userspace network
service. If they can do that once, they can do that a bunch of times,
and gain code execution on different machines every time.

Before trying to exploit a kernel memory corruption to elevate
privileges on a machine, they can test the SLAB properties of the
running kernel to make sure it's as they wish (eg: with timing side
channels like in the SLUBStick paper). So with RANDOM_KMALLOC_CACHES,
attackers can just keep retrying their attacks until they land on a
machine where the types T and S are collocated and only then proceed
with their exploit.

With TYPED_KMALLOC_CACHES (and with SLAB_VIRTUAL hopefully someday),
they are simply never able to cross the "objects without pointers" to
"objects with pointers" boundary which really gets in the way of many
exploitation techniques and feels at least to me like a much stronger
security boundary.

This limit of RANDOM_KMALLOC_CACHES may not be as relevant in other
deployments (eg: on a smartphone) but it makes me strongly prefer
TYPED_KMALLOC_CACHES for server use cases at least.

Powered by blists - more mailing lists