Status: draft in progress

Overview

This article compares two allocator designs:

  • Linux SLUB, which can merge compatible caches of similar-sized objects.
  • XNU zones, which keep allocation domains separated by zone.

The article is not meant to argue that one design is simply better than the other. The goal is to understand the tradeoff.

SLUB’s cache merging can reduce memory overhead and allocator complexity. XNU’s zone isolation gives stronger type separation. Both choices make sense in context, and both have security and engineering consequences.

Main question

The article is built around one question:

What changes when kernel objects of different types can share allocator backing pages?

This question matters because allocator behavior can influence how memory corruption bugs behave in practice.

Notes being developed

Linux SLUB

Current notes cover:

  • slab caches
  • object size and alignment
  • cache flags
  • when caches are considered mergeable
  • the role of find_mergeable()
  • how merging affects object placement

XNU zones

Current notes cover:

  • zones as allocation domains
  • per-zone page ownership
  • zone-based type separation
  • how this differs from SLUB-style merging

Hardening implications

Current notes cover:

  • use-after-free behavior
  • object replacement
  • type confusion
  • cross-cache attacks
  • why type isolation can affect exploitability

Linux hardening mechanisms

The article also tracks Linux mechanisms related to stronger isolation, including:

  • SLAB_NEVER_MERGE
  • RANDOM_KMALLOC_CACHES
  • proposed SLAB_VIRTUAL

Current status

The background section is being written.

I am currently checking the historical path from Bonwick’s SLAB design, through Linux SLAB and SLUB, to the removal of the old SLAB allocator in Linux 6.5.

The article will be updated as the source reading and references become cleaner.