Logo
ScienceStack
Table of Contents
Fetching ...
Sign In

SJMalloc: the security-conscious, fast, thread-safe and memory-efficient heap allocator

Stephan Bauroth

TL;DR

SJMalloc is a general-purpose, high-performance allocator that stores its metadata out-of-band, away from the application's data on the heap, and demonstrates a ~6% performance improvement compared to GLibcs allocator, while using only ~5% more memory.

Abstract

Heap-based exploits that leverage memory management errors continue to pose a significant threat to application security. The root cause of these vulnerabilities are the memory management errors within the applications, however various hardened allocator designs have been proposed as mitigation. A common feature of these designs is the strategic decision to store heap metadata separately from the application data in use, thereby reducing the risk of metadata corruption leading to security breaches. Despite their potential benefits, hardened allocators have not been widely adopted in real-world applications. The primary barrier to their adoption is the performance overheads they introduce. These overheads can negatively impact the efficiency and speed of applications, which is a critical consideration for developers and system administrators. Having learned from previous implementations, we developed SJMalloc, a general-purpose, high-performance allocator that addresses these concerns. SJMalloc stores its metadata out-of-band, away from the application's data on the heap. This design choice not only enhances security but also improves performance. Across a variety of real-world workloads, SJMalloc demonstrates a ~6% performance improvement compared to GLibcs allocator, while using only ~5% more memory. Furthermore, SJMalloc successfully passes the generic elements of the GLibc malloc testsuite and can thus be used as a drop-in replacement for the standard allocator, offering an easy upgrade path for enhanced security and performance without requiring changes to existing applications.

SJMalloc: the security-conscious, fast, thread-safe and memory-efficient heap allocator

TL;DR

SJMalloc is a general-purpose, high-performance allocator that stores its metadata out-of-band, away from the application's data on the heap, and demonstrates a ~6% performance improvement compared to GLibcs allocator, while using only ~5% more memory.

Abstract

Heap-based exploits that leverage memory management errors continue to pose a significant threat to application security. The root cause of these vulnerabilities are the memory management errors within the applications, however various hardened allocator designs have been proposed as mitigation. A common feature of these designs is the strategic decision to store heap metadata separately from the application data in use, thereby reducing the risk of metadata corruption leading to security breaches. Despite their potential benefits, hardened allocators have not been widely adopted in real-world applications. The primary barrier to their adoption is the performance overheads they introduce. These overheads can negatively impact the efficiency and speed of applications, which is a critical consideration for developers and system administrators. Having learned from previous implementations, we developed SJMalloc, a general-purpose, high-performance allocator that addresses these concerns. SJMalloc stores its metadata out-of-band, away from the application's data on the heap. This design choice not only enhances security but also improves performance. Across a variety of real-world workloads, SJMalloc demonstrates a ~6% performance improvement compared to GLibcs allocator, while using only ~5% more memory. Furthermore, SJMalloc successfully passes the generic elements of the GLibc malloc testsuite and can thus be used as a drop-in replacement for the standard allocator, offering an easy upgrade path for enhanced security and performance without requiring changes to existing applications.

Paper Structure

This paper contains 33 sections, 3 figures, 1 table.

Table of Contents

  1. Introduction
  2. Outline
  3. Background
  4. Arbitrary write by the allocator
  5. Concurrent uses of a given block
  6. Terminology
  7. Design
  8. Thread Synchronization
  9. No second growing memory range
  10. No caching
  11. Size classes
  12. Implementation
  13. Bins
  14. Fixed bins (FBINs)
  15. Variable bins (VBINs)
  16. ...and 18 more sections

Figures (3)

  • Figure 1: Spatial list composition in free heads: the previous cell is a used head, thus removing the necessity to store its index, the next cell is not, making space to store the next used heads index.
  • Figure 2: A portion of a VBIN and its associated heap memory. The VBINs cells are shown at the top, the heap memory at the bottom. Striped memory denotes used memory, white memory is free. Each cell contains the metadata of the memory block starting in the cell's associated memory. Note the forward reference in cell 121 for the free head in cell 120 and the backward reference in cell 124 for the free head in cell 125 - while cell 119 does not contain a backwards reference for the free head in cell 120 because it already is the used head that would be referenced.
  • Figure 3: Normalized runtime (left) and normalized memory usage (right) of all real-world benchmarks in mimalloc-bench. In both cases, lower is better.