TUM Logo

Hardening the Linux Kernel Slab Allocator

Hardening the Linux Kernel Slab Allocator

Supervisor(s): Sergej Proskurin
Status: finished
Topic: Linux stuff
Author: Marius Momeu
Submission: 2020-06-15
Type of Thesis: Masterthesis

Description

The Linux Kernel SLUB implementation lacks heap object metadata
isolation due to itsobsessive aim at cache line usage and memory space optimizations.
Consequently, SLUB architects have designed SLUB to reuse the data segment of an
allocated object to store freelist information when the object is freed. Hence, attacks against
heap metadata, such as Object-Out-of-Bounds, Use-After-Free, Double Free and Invalid
Free can easily emerge in the presence of an object mismanagement. The objective
of this work is to design a hardened allocator strategy that isolates the freepointer of
each freed object, such that the aforementioned complications are mitigated even in the
presence of a critical Kernel subsystem or driver vulnerability. Our approach leverages
Intel’s Virtualization extensions and the Xen’s altp2m subsystem to orchestrate an
in-place freepointer isolation mechanism that stores and retrieves the freepointer of an
object in segregated physical pages which are protected under the default memory view.
The freepointer access is performed by dynamically switching to a carefully configured
memory view which relaxes the permissions of the isolated metadata pages. In addition,
an isolated physical memory page is arranged to host freepointers belonging to objects
from different slabs, therefore, utilizing the full capacity of the physical frame. Our
approach requires minimal adjustments in the base implementation of SLUB, as we
mostly re-organize the allocator at the physical address space layer, while in the virtual
address space we only modify the location of the freepointer within its objects.
Our allocator induces a negligible memory overhead of only 5% on commodity Linux sessions 
with high loads of object caches and slabs. The low indicator is obtained thanks to the
complete utilization of the shared isolated physical pages that occupy all their memory words
with freepointers originating from various equally-sized slabs. Moreover, the performance assessment of our allocator yields encouraging execution latencies in most of the tested cases, with only a few exceptions that do not mirror real- world scenarios. In addition, according to our performance evaluation, the allocator proves scalability to multi-processing systems as it does not increase its runtime latency when more CPUs are enabled on the host machine.