IUBIK: Isolating User Bytes in Commodity Operating System Kernels via Memory Tagging Extensions

IUBIK: Isolating User Bytes in Commodity Operating System Kernels via Memory Tagging Extensions

Speakers: Marius Momeu, Research Assistant, TU Munich; Alexander J. Gaidis, PhD Student, Brown University; Jasper von der Heidt, Research Assistant, TU Munich; Vasileios P. Kemerlis, Assistant Professor, Brown University

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=OdFjDgJ5HqY

Overview

Despite decades of dedicated research and significant advancements in software engineering, memory safety vulnerabilities continue to pose a formidable threat to the integrity and security of commodity operating system kernels. These errors, often leading to critical exploits, remain a primary vector for attackers seeking to gain privileged access or disrupt system operations. The IUBIK project, presented by Marius Momeu from TU Munich, directly addresses this persistent challenge by introducing a novel approach that leverages cutting-edge hardware features to fundamentally alter how user-controlled data is handled within kernel memory.

UBIK, a collaborative effort involving researchers from TU Munich and Brown University, proposes a multi-faceted mitigation strategy. At its core, it harnesses ARM's Memory Tagging Extension (MTE), a sophisticated hardware capability designed to enforce memory safety at a granular level. The system isolates user data, rewrites problematic kernel objects that mix user data with security-critical metadata, and employs a dynamic profiling framework to identify potentially vulnerable code paths. This comprehensive approach aims to disrupt common exploitation patterns, particularly those involving type confusion and heap overflows, which have historically been abused to compromise kernel integrity.

The significance of UBIK lies in its proactive and architectural solution to a deeply entrenched problem. By using hardware-backed memory tagging, UBIK moves beyond purely software-based mitigations, offering a stronger guarantee of isolation and integrity. The presented research demonstrates that this approach is not only highly effective, mitigating 90% of recent exploits analyzed, but also practical, incurring negligible performance and memory overhead. This makes UBIK a compelling proposition for enhancing the resilience of modern operating system kernels against a wide array of memory safety attacks.

Background

▶ Watch: Common exploitation pattern in OS kernels (0:28)

The landscape of kernel security is continually shaped by the pervasive nature of memory safety errors. Despite extensive efforts in static analysis, fuzzing, and various software-based hardening techniques, vulnerabilities such as use-after-free and heap overflows persist, allowing attackers to escalate privileges or execute arbitrary code within the kernel. A common theme observed in many successful kernel exploits is a two-stage attack pattern that IUBIK specifically targets.

Firstly, attackers frequently exploit a kernel object that stores user-controlled data. This data, which can be manipulated by an attacker, is then leveraged to induce type confusion with a separate kernel object that contains security-critical metadata, such as function pointers, data pointers, or other sensitive control structures. The ability to overwrite or manipulate these critical fields through user-controlled input allows attackers to redirect control flow, leak sensitive information, or achieve arbitrary write primitives, forming the basis for code reuse attacks (e.g., Return-Oriented Programming) or data-oriented attacks.

Secondly, to achieve this type confusion, attackers often rely on elastic objects. These are kernel objects whose size can be dynamically controlled by the attacker, typically through arguments passed to a system call. The ability to dictate the size of these objects is crucial because it allows attackers to meticulously "massage" the kernel heap allocator. By allocating a series of user-controlled elastic objects of specific sizes, attackers can ensure they are placed in memory regions adjacent to or overlapping with a target security-critical object.

The Linux kernel, like many other operating systems, provides standard mechanisms for interaction between user space and kernel space, primarily through functions like copy_from_user and copy_to_user. These functions are fundamental for transferring data, but they also represent potential entry points for malicious input. A prime example highlighted in the talk is the add_key system call, which utilizes copy_from_user to process user-provided key data. Within this system call, a heap object of type user_key_payload is allocated. Crucially, the size of this allocation is controlled by a user-supplied variable, making user_key_payload a classic example of an elastic object.

Further complicating matters, the struct user_key_payload definition itself demonstrates a dangerous pattern: it mixes user data (stored in a flexible array field) with object metadata, such as a destructor pointer. This combination is highly attractive for exploitation. If attackers can control the size and content of such an elastic object, they can exploit various heap-based vulnerabilities:

1. Same-cache attacks: If a security-critical object (e.g., a victim of a use-after-free bug) is allocated in a specific KASLR cache, attackers can manipulate the heap by allocating user_key_payload objects of matching sizes. This allows them to allocate the user-controlled object in the same KASLR cache, potentially overlapping the freed security-critical object and manipulating its contents with user-controlled data.
2. Cross-cache attacks: Even if the security-critical object and the user-controlled object are allocated in different KASLR caches, attackers can still orchestrate an attack. They can trick the underlying page allocator into reallocating a physical page that previously stored the security-critical object for a new allocation that stores user-controlled user_key_payload objects. This re-establishes type confusion, allowing manipulation of the security-critical object's original memory location.
3. Heap overflows: Attackers can "massage" the heap allocator to ensure that a user-controlled object, which is the victim of a heap overflow, is placed immediately adjacent to a security-critical object on the same memory page. The overflow from the user-controlled object can then corrupt the contents of the adjacent security-critical object.

These primitives, often combined in sophisticated exploits, are so powerful that they can be leveraged to compromise almost any heap-based vulnerability in the Linux kernel. This critical observation forms the impetus behind UBIK: to fundamentally segregate user data from security-critical metadata, thereby neutralizing these prevalent and potent attack vectors.

Key Findings

▶ Watch: UBK's solution: ARM Memory Tagging Extension (4:10)

The UBIK project presents several pivotal findings and contributions that collectively advance the state of kernel memory safety:

1. Novel Memory Isolation Approach: UBIK proposes and implements a groundbreaking memory isolation strategy that leverages ARM's Memory Tagging Extension (MTE). This hardware-backed approach effectively segregates user-controlled data from security-critical kernel metadata within physical memory. By dividing kernel heap memory into two distinct isolation domains, DOM U for user data and DOM K for everything else, UBIK establishes a strong architectural barrier against type confusion and heap overflows.
2. Effective Mitigation of Common Exploitation Patterns: The core technical contribution of UBIK is its ability to directly mitigate the most prevalent and powerful kernel exploitation patterns. By enforcing strict tag-based access control, UBIK neutralizes same-cache attacks, cross-cache attacks, and heap overflows that rely on manipulating user data to corrupt kernel metadata. This is achieved through the architectural design of tagged memory domains and the strategic rewriting of problematic kernel objects.
3. High Security Effectiveness: Through a rigorous evaluation against a dataset of 31 recent exploits targeting use-after-free and heap overflow vulnerabilities in Linux, UBIK demonstrated remarkable security effectiveness. The prototype was able to mitigate 90% of these real-world exploits, showcasing its robust protection capabilities against contemporary kernel attack techniques.
4. Negligible Performance and Memory Overhead: A critical finding for the practicality of any kernel-level security solution is its impact on system performance and resource consumption. UBIK was evaluated on a Pixel 8 device with MTE support, demonstrating negligible performance overhead across a diverse set of benchmarks, including LMBench and Phoronix. While some worst-case scenarios (e.g., Fstat and OpenClose) showed minor impacts, most tests incurred almost no overhead. In terms of memory, UBIK required only 2.17% more memory than a vanilla kernel, as measured by its maximum resident set size during kernel boot. This low overhead makes UBIK a viable candidate for deployment in commodity operating systems.
5. Dynamic Profiling Framework (User Copy Profiler): UBIK introduces a novel dynamic profiling framework designed to identify kernel code paths that handle user data. The User Copy Profiler extends Linux's existing memory allocation profiling features to record alloc, user_copy, mem_copy, and free call sites that involve user data. This tool is invaluable for systematically identifying kernel objects and allocation sites that are susceptible to user-controlled manipulation, enabling proactive security hardening.
6. Identification of Vulnerable Kernel Objects: Using the User Copy Profiler with a diverse suite of user space workloads, UBIK identified a significant number of kalloc sites that allocate user-controlled objects in the Linux kernel: 292 privileged and 212 unprivileged sites. This data provides concrete targets for instrumentation and rewriting efforts, highlighting the widespread nature of the problem.

These findings collectively underscore UBIK's potential to significantly enhance kernel security by leveraging hardware capabilities, offering a high degree of protection with minimal impact on system resources.

Technical Deep Dive

▶ Watch: UBK's DOM U and DOM K isolation domains (4:45)

UBIK's core technical innovation lies in its ingenious application of ARM's Memory Tagging Extension (MTE) to enforce strict isolation between user-controlled data and security-critical kernel metadata. MTE is a powerful hardware feature available in modern ARM architectures that provides fine-grained memory access control. It operates by associating a memory tag with each 16-byte memory granule in RAM. Simultaneously, pointers that access this memory are also imbued with a tag. An access is only permitted if the tag of the pointer matches the tag of the memory granule it attempts to access. Any mismatch triggers a hardware exception, effectively preventing unauthorized memory operations.

UBIK leverages this mechanism to establish two distinct isolation domains within the kernel's heap memory:

1. DOM U (Domain User): This domain is specifically designated to store user-controlled data. Physical pages allocated within DOM U are tagged with a unique tag U.
2. DOM K (Domain Kernel): This domain stores all other kernel data, including security-critical metadata and general kernel objects. Physical pages allocated within DOM K are tagged with a distinct tag K.

To facilitate memory allocation within these new domains, UBIK introduces a new set of KASLR caches called KLO UBK and a new memory allocation flag, GFP UBK. When a kernel subsystem needs to allocate memory for user-controlled data, it invokes kalloc with the GFP_UBK flag. This directs the allocation to KLO UBK, ensuring the memory is reserved in DOM U and tagged appropriately with tag U. Conversely, standard kalloc invocations, which typically allocate kernel metadata or other non-user-controlled data, continue to reserve memory in DOM K with tag K.

This segregated architecture provides robust mitigation against the attack patterns discussed in the background:

• Mitigating Same-Cache Attacks: By forcing user-controlled objects into DOM U and security-critical kernel objects into DOM K, UBIK inherently prevents them from being allocated in the same KASLR cache with identical memory tags. Even if an attacker manages to trigger a use-after-free on a kernel object in DOM K, they cannot reallocate that memory with a user-controlled object from DOM U and manipulate its contents, because the tags would mismatch, and MTE would block the access.
• Mitigating Cross-Cache Attacks: Cross-cache attacks rely on the page allocator reusing physical pages across different KASLR caches, allowing an attacker to gain control over a previously security-critical memory region. UBIK thwarts this by enforcing a retagging policy. Whenever a physical page is reallocated from one domain (e.g., DOM K) to another (e.g., DOM U), its memory tag is updated to reflect the new domain's tag. Consequently, any dangling pointers from the page's previous life in DOM K would still carry tag K, while the page itself would now have tag U. Any attempt to dereference such a dangling pointer would result in a tag mismatch, and MTE would prevent the access, thus neutralizing the attack.
• Neutralizing Heap Overflows: The hardware-enforced tag separation also inherently prevents overflows from one domain into another. If a user-controlled object in DOM U (tagged U) is placed next to a security-critical object in DOM K (tagged K) on the same physical page, an overflow from the DOM U object would attempt to write into the DOM K object's memory. However, the pointer used for the overflow would carry tag U, while the target memory would have tag K. MTE would immediately block this access, preventing the corruption.

A significant challenge for UBIK arises from existing kernel objects that mix user data with security-critical metadata within the same structure. The user_key_payload struct is a prime example, where a flexible array for user data coexists with sensitive object metadata like a destructor pointer. Simply allocating such an object in DOM U would not solve the problem, as attackers could still corrupt the metadata fields within that same object.

To address this, UBIK employs a strategy of rewriting such objects to decouple user-controlled fields from security-critical ones. Taking the user_key_payload example, UBIK transforms the flexible array into a pointer. The add_key system call is then adjusted to use this new object layout:

1. The initial kalloc invocation for the user_key_payload object is modified to reserve only a fixed size for the metadata fields. This fixed-size object is then allocated in DOM K.
2. A new kalloc invocation is added, specifically using the GFP_UBK flag, to reserve a separate block of memory in DOM U where the actual user-controlled data will be stored. The pointer within the DOM K user_key_payload object then points to this segregated DOM U buffer.
3. Finally, a new kfree invocation is introduced to explicitly release the memory for the segregated user buffer when the key object is destroyed.

This rewriting process ensures that even for historically problematic structures, user data is strictly isolated from kernel metadata, with MTE enforcing the separation at a hardware level.

To scale this manual instrumentation and rewriting effort, and to identify other potentially vulnerable structures, UBIK developed the User Copy Profiler. This dynamic profiling framework extends Linux's existing memory allocation profiling features. It's designed to record alloc, user_copy, mem_copy, and free call sites that involve user data. The profiler was used to generate a comprehensive dataset by executing a diverse suite of user space workloads, including functional tests and performance benchmarks, run both as privileged and unprivileged users. This profiling revealed 292 privileged and 212 unprivileged kalloc sites that allocate user-controlled objects in Linux, providing concrete targets for UBIK's instrumentation.

Finally, the talk briefly mentions a sophisticated detail: in some corner cases, UBIK had to incorporate ARM's Pointer Authentication (PAC) to protect certain pointers. PAC is another ARM security feature that uses cryptographic hashes to protect pointers from being corrupted, adding an extra layer of defense for critical control flow integrity. This indicates a deep understanding and utilization of available hardware security primitives to achieve robust protection.

Demo / Proof of Concept

▶ Watch: Rewriting kernel objects to decouple user data (6:45)

The UBIK project's practical viability was thoroughly demonstrated through a prototype implementation and a comprehensive evaluation of its security effectiveness, performance, and memory overhead. This evaluation serves as the "Proof of Concept" for the proposed architectural changes.

Prototype Implementation Details:

The UBIK prototype involved manually rewriting 79 allocation sites and 23 kernel objects. These targets were identified through the use of the User Copy Profiler during various system activities, specifically kernel boot, execution of LMBench benchmarks, and Phoronix benchmarks. This selective rewriting focused on the most critical and frequently abused code paths and data structures, such as the user_key_payload example discussed earlier, to demonstrate the core principles of UBIK.

Evaluation Platform:

All performance and memory overhead benchmarks were conducted on a Pixel 8 smartphone. This choice of hardware is significant because the Pixel 8 features an ARM processor with full support for the Memory Tagging Extension (MTE), allowing for a realistic assessment of UBIK's impact when leveraging the intended hardware capabilities.

Security Effectiveness Evaluation:

To assess UBIK's ability to withstand real-world attacks, the researchers analyzed 31 recent exploits targeting both use-after-free and heap overflow vulnerabilities in the Linux kernel. These exploits represent a cross-section of contemporary kernel vulnerabilities and attack techniques. The analysis determined that UBIK's proposed mitigations, specifically the hardware-backed isolation of user data and the rewriting of mixed objects, were capable of mitigating a remarkable 90% of these exploits. This high success rate underscores UBIK's robust defensive posture against prevalent kernel memory safety attacks. While the talk mentions that details on the unmitigated 10% are in the paper, the overwhelming majority coverage highlights the system's strength.

Performance Benchmarks:

The performance impact of UBIK was rigorously measured using standard industry benchmarks:

• LMBench: UBIK incurred its worst-case performance overhead on specific LMBench tests, namely Fstat and OpenClose. While the exact percentage of overhead for these cases was not explicitly stated in the talk, the overall conclusion was "almost no overhead at all in all the other benchmarks from LMBench," implying that even the worst-case scenarios were likely minimal.
• Phoronix: Across all tests within the Phoronix benchmark suite, UBIK demonstrated almost no overhead at all. This indicates that for a broad range of system workloads, the MTE-enabled isolation and object rewriting introduce negligible performance degradation.

Memory Overhead:

Memory consumption is another critical factor for kernel-level modifications. UBIK's memory overhead was measured by booting the kernel on the Pixel 8 and computing its maximum resident set size. The results showed that UBIK required only 2.17% more memory than a vanilla (unmodified) kernel. This low memory footprint makes UBIK highly practical for deployment in resource-constrained environments or systems where memory efficiency is paramount.

The combination of a well-defined prototype, evaluation on MTE-enabled hardware, strong security effectiveness against real exploits, and minimal performance and memory impact provides compelling evidence for the feasibility and benefits of the UBIK approach.

Defensive Implications

▶ Watch: Dynamic profiling to discover new vulnerabilities (8:00)

The UBIK project offers profound implications for kernel developers, security architects, and system administrators striving to enhance the resilience of operating systems against memory safety vulnerabilities. The findings suggest a paradigm shift in how kernel memory is managed and protected, moving towards hardware-enforced guarantees.

1. Embrace MTE-Enabled Hardware: The most immediate defensive implication is the strong encouragement to adopt and leverage hardware platforms equipped with ARM's Memory Tagging Extension (MTE). UBIK unequivocally demonstrates that MTE is not merely an academic feature but a powerful, practical primitive for achieving fundamental memory safety at the hardware level. Organizations should prioritize hardware that supports such capabilities to build a more secure foundation for their systems.

1. Architectural Isolation of User Data: Kernel developers should re-evaluate existing kernel memory management strategies with an emphasis on strictly isolating user-controlled data from security-critical kernel metadata. UBIK's concept of DOM U and DOM K provides a blueprint for this architectural separation. This involves modifying memory allocators (e.g., kalloc) to recognize and enforce distinct allocation domains based on data origin and sensitivity.

1. Proactive Rewriting of Mixed-Type Objects: A significant vulnerability identified by UBIK is the mixing of user data and kernel metadata within single kernel structures (e.g., user_key_payload). Defenders and kernel developers must proactively identify and refactor such "elastic" or mixed-type objects. This typically involves decoupling the user-controlled buffer into a separately allocated, tagged region of memory, pointed to by a pointer within the main kernel object. This structural change eliminates a major class of type confusion and overflow vulnerabilities.

1. Continuous Profiling for Vulnerable Code Paths: The User Copy Profiler developed for UBIK highlights the importance of dynamic profiling. Implementing similar tools or integrating such capabilities into kernel development workflows can help identify new or overlooked kalloc sites and user_copy interactions that handle user-controlled data. This proactive identification is crucial for comprehensive protection, allowing developers to instrument or rewrite vulnerable code paths before they are exploited.

1. Layered Security with Hardware Primitives: UBIK showcases how MTE can be combined with other hardware security features, such as Pointer Authentication (PAC), to address specific corner cases and provide layered protection. Defenders should explore how to integrate and orchestrate various hardware-backed security primitives to create a more robust defense-in-depth strategy against sophisticated attacks.

1. Guidance for Future Kernel Design: The UBIK research provides a clear direction for the design of future operating system kernels. Moving forward, kernel architects should consider MTE as a foundational security primitive, incorporating tag-based memory management from the ground up rather than as an afterthought. This shift can lead to kernels that are inherently more resilient to memory safety errors.

1. Addressing Legacy Systems: For existing systems without MTE support, the principles behind UBIK still offer valuable insights. The understanding of common exploitation patterns and the need for data segregation should drive continued investment in software-based mitigations like hardened allocators, object type awareness, and bounds checking, even as the industry transitions to MTE-enabled hardware.

In essence, UBIK empowers defenders by offering a concrete, evaluated, and performant strategy to combat a long-standing class of critical vulnerabilities, moving kernel security towards a more hardware-assured future.

Key Takeaways

• Hardware-Backed Isolation is Effective: ARM's Memory Tagging Extension (MTE) provides a powerful hardware primitive for enforcing memory safety, enabling a strong architectural separation of user-controlled data from kernel metadata.
• UBIK Mitigates Core Exploitation Patterns: By creating distinct DOM U and DOM K memory domains, UBIK effectively neutralizes common kernel exploitation techniques such as same-cache attacks, cross-cache attacks, and heap overflows, significantly raising the bar for attackers.
• Object Rewriting is Crucial for Mixed Structures: Kernel objects that dangerously mix user data with security-critical metadata must be identified and rewritten to decouple these elements, ensuring complete isolation and preventing type confusion within single structures.
• Dynamic Profiling Identifies Vulnerabilities: Tools like the User Copy Profiler are essential for dynamically identifying kernel kalloc sites and code paths that handle user data, enabling proactive instrumentation and hardening efforts against future exploits.
• High Security with Negligible Overhead: UBIK demonstrates that robust kernel memory safety, mitigating 90% of recent exploits, can be achieved with minimal impact on performance (negligible) and memory consumption (2.17% increase).
• Future of Kernel Security: The UBIK project points towards a future where hardware-assisted memory tagging becomes a fundamental component of operating system kernel design, offering a more secure and resilient computing environment.

About the Speaker(s)

The UBIK project is the result of a collaborative research effort involving academics from two prominent institutions. The talk was presented by Marius Momeu from TU Munich. He is credited alongside Alexander J. Gaidis and Vasileios P. Kemerlis from Brown University, and Jasper von der Heidt, also from TU Munich. Their collective expertise in systems security and operating systems research underpins the innovative approach presented in UBIK.