Hardening the kernel with allocation tokens and bootpatch-SLR [LWN.net]
LWN<br>.net<br>News from the source
Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments
LWN FAQ<br>Write for us
Edition Return to the Front page
User:<br>Password: |
Log in /<br>Subscribe /<br>Register
Hardening the kernel with allocation tokens and bootpatch-SLR
LWN.net needs you!
Without subscribers, LWN would simply not exist. Please consider<br>signing up for a subscription and helping<br>to keep LWN publishing.
By Jonathan Corbet<br>June 25, 2026
There is a lot of work going into eliminating exploitable bugs from the<br>kernel and preventing the addition of new ones. Even if this work is<br>maximally successful, though, there is no chance that the kernel will be<br>free of these bugs anytime soon. Thus, there is also ongoing interest in<br>hardening the kernel to make the existing bugs more difficult to exploit.<br>The upcoming 7.2 kernel release will include a change to how dynamically<br>allocated structures are placed in memory to make them harder to overwrite,<br>while a project to randomize structure layout at boot time has a rather<br>longer timeline.
Memory partitioning with allocation tokens
The kernel's slab allocator handles memory management for small objects.<br>Allocations come from buckets of fixed-size (mostly powers of two) objects,<br>and many types of objects with the same bucket size can be allocated from<br>the same slab. This arrangement allows efficient use of memory, but the<br>intermingling of object types in this way can make the kernel more<br>vulnerable to certain types of exploits. If the kernel can be convinced to<br>overrun an object of a given type, it may end up accessing or corrupting<br>other objects with entirely unrelated types. Additionally, heap-spraying<br>attacks may be used to fill much of the kernel's memory space with<br>known data, which can make other sorts of bugs (such as an erroneous<br>pointer dereference) easier to exploit.
Back in 2023, a set of patches was merged<br>in an attempt to harden the kernel against such attacks; this mechanism<br>works by partitioning the memory used by the slab allocator to satisfy<br>requests. Rather than use one set of slabs to provide (for example)<br>64-byte memory chunks, the allocator uses sixteen of them. The specific<br>slab used for any given request is chosen randomly, but in such a way that<br>the same slab is always used for allocations made at the same call site.<br>In this way, the ability to fill memory with techniques like heap spraying<br>is much reduced. The ability to overwrite a targeted object with a buffer<br>overflow is also reduced; most object types will be located in distant<br>slabs, and the specific mix of object types in any given slab will differ<br>from one boot to the next.
Partitioning that is randomized in this way makes many attacks harder, but<br>it is a probabilistic defense. It may separate a target object from the<br>vulnerable object most of the time, but it will still put them into the<br>same slab one boot out of sixteen. In multi-system cloud deployments,<br>some systems will certainly end up with an attacker-friendly placement of<br>vulnerable objects. Naturally, security-oriented kernel developers would<br>like to do better than that.
One attempt to do better is type-based slab<br>partitioning, by Marco Elver, which was merged<br>for the 7.2 release. As its name would suggest, it works by separating<br>allocations based on the type of the object being allocated rather than the<br>address of the allocation call site.
To do so, this feature takes advantage of the allocation tokens<br>feature that is available with the Clang 23 compiler. In short,<br>this feature provides a new compiler built-in function,<br>__builtin_infer_alloc_token(), which generates an integer token<br>value from the type(s) of the argument(s) passed into it. That token, in<br>turn, can be used to select the partition from which an object will be<br>allocated. The result is that objects of the same type will always be<br>allocated from the same partition, even if there are several call sites<br>performing the allocations. A structure involved in a vulnerability will<br>always be confined to a single partition, and will always be separated from<br>most other structure types.
As an additional hardening feature, the generation of the token takes into<br>account whether the type(s) in question are structures that contain<br>pointers; the space for tokens representing pointer-containing types is<br>disjoint from the space for all other types. As a result, types that do<br>not contain pointers are kept separate from those that do, making any<br>overrun vulnerabilities with those types harder to exploit for the purpose<br>of overwriting pointers.
The potential downside of this approach is that the mapping from types to<br>partitions is now deterministic and, thus, predictable by attackers. The<br>older, randomized partitioning is still available as a configuration option<br>for those who prefer it. Distributors will have to make a choice, though,<br>regarding which hardening variant (if...