GWP-ASan¶

Introduction
GWP-ASan vs. ASan
Design
Usage
- Options
- Example

Introduction ¶

GWP-ASan is a sampled allocator framework that assists in finding use-after-free and heap-buffer-overflow bugs in production environments. It informally is a recursive acronym, “GWP-ASan Will Provide Allocation SANity”.

GWP-ASan is based on the classic Electric Fence Malloc Debugger, with a key adaptation. Notably, we only choose a very small percentage of allocations to sample, and apply guard pages to these sampled allocations only. The sampling is small enough to allow us to have very low performance overhead.

There is a small, tunable memory overhead that is fixed for the lifetime of the process. This is approximately ~40KiB per process using the default settings, depending on the average size of your allocations.

GWP-ASan vs. ASan ¶

Unlike AddressSanitizer, GWP-ASan does not induce a significant performance overhead. ASan often requires the use of dedicated canaries to be viable in production environments, and as such is often impractical.

GWP-ASan is only capable of finding a subset of the memory issues detected by ASan. Furthermore, GWP-ASan’s bug detection capabilities are only probabilistic. As such, we recommend using ASan over GWP-ASan in testing, as well as anywhere else that guaranteed error detection is more valuable than the 2x execution slowdown/binary size bloat. For the majority of production environments, this impact is too high, and GWP-ASan proves extremely useful.

Design ¶

Please note: The implementation of GWP-ASan is largely in-flux, and these details are subject to change. There are currently other implementations of GWP-ASan, such as the implementation featured in Chromium. The long-term support goal is to ensure feature-parity where reasonable, and to support compiler-rt as the reference implementation.

Allocator Support ¶

GWP-ASan is not a replacement for a traditional allocator. Instead, it works by inserting stubs into a supporting allocator to redirect allocations to GWP-ASan when they’re chosen to be sampled. These stubs are generally implemented in the implementation of malloc(), free() and realloc(). The stubs are extremely small, which makes using GWP-ASan in most allocators fairly trivial. The stubs follow the same general pattern (example malloc() pseudocode below):

#ifdef INSTALL_GWP_ASAN_STUBS
  gwp_asan::GuardedPoolAllocator GWPASanAllocator;
#endif

void* YourAllocator::malloc(..) {
#ifdef INSTALL_GWP_ASAN_STUBS
  if (GWPASanAllocator.shouldSample(..))
    return GWPASanAllocator.allocate(..);
#endif

  // ... the rest of your allocator code here.
}

Then, all the supporting allocator needs to do is compile with -DINSTALL_GWP_ASAN_STUBS and link against the GWP-ASan library! For performance reasons, we strongly recommend static linkage of the GWP-ASan library.

Guarded Allocation Pool ¶

The core of GWP-ASan is the guarded allocation pool. Each sampled allocation is backed using its own guarded slot, which may consist of one or more accessible pages. Each guarded slot is surrounded by two guard pages, which are mapped as inaccessible. The collection of all guarded slots makes up the guarded allocation pool.

Buffer Underflow/Overflow Detection ¶

We gain buffer-overflow and buffer-underflow detection through these guard pages. When a memory access overruns the allocated buffer, it will touch the inaccessible guard page, causing memory exception. This exception is caught and handled by the internal crash handler. Because each allocation is recorded with metadata about where (and by what thread) it was allocated and deallocated, we can provide information that will help identify the root cause of the bug.

Allocations are randomly selected to be either left- or right-aligned to provide equal detection of both underflows and overflows.

Use after Free Detection ¶

The guarded allocation pool also provides use-after-free detection. Whenever a sampled allocation is deallocated, we map its guarded slot as inaccessible. Any memory accesses after deallocation will thus trigger the crash handler, and we can provide useful information about the source of the error.

Please note that the use-after-free detection for a sampled allocation is transient. To keep memory overhead fixed while still detecting bugs, deallocated slots are randomly reused to guard future allocations.

Usage ¶

GWP-ASan already ships by default in the Scudo Hardened Allocator, so building with -fsanitize=scudo is the quickest and easiest way to try out GWP-ASan.

Options ¶

GWP-ASan’s configuration is managed by the supporting allocator. We provide a generic configuration management library that is used by Scudo. It allows several aspects of GWP-ASan to be configured through the following methods:

When the GWP-ASan library is compiled, by setting -DGWP_ASAN_DEFAULT_OPTIONS to the options string you want set by default. If you’re building GWP-ASan as part of a compiler-rt/LLVM build, add it during cmake configure time (e.g. cmake ... -DGWP_ASAN_DEFAULT_OPTIONS="..."). If you’re building GWP-ASan outside of compiler-rt, simply ensure that you specify -DGWP_ASAN_DEFAULT_OPTIONS="..." when building optional/options_parser.cpp).
By defining a __gwp_asan_default_options function in one’s program that returns the options string to be parsed. Said function must have the following prototype: extern "C" const char* __gwp_asan_default_options(void), with a default visibility. This will override the compile time define;
Depending on allocator support (Scudo has support for this mechanism): Through the environment variable GWP_ASAN_OPTIONS, containing the options string to be parsed. Options defined this way will override any definition made through __gwp_asan_default_options.

The options string follows a syntax similar to ASan, where distinct options can be assigned in the same string, separated by colons.

For example, using the environment variable:

GWP_ASAN_OPTIONS="MaxSimultaneousAllocations=16:SampleRate=5000" ./a.out

Or using the function:

extern "C" const char *__gwp_asan_default_options() {
  return "MaxSimultaneousAllocations=16:SampleRate=5000";
}

The following options are available:

Option	Default	Description
Enabled	true	Is GWP-ASan enabled?
PerfectlyRightAlign	false	When allocations are right-aligned, should we perfectly align them up to the page boundary? By default (false), we round up allocation size to the nearest power of two (2, 4, 8, 16) up to a maximum of 16-byte alignment for performance reasons. Setting this to true can find single byte buffer-overflows at the cost of performance, and may be incompatible with some architectures.
MaxSimultaneousAllocations	16	Number of simultaneously-guarded allocations available in the pool.
SampleRate	5000	The probability (1 / SampleRate) that a page is selected for GWP-ASan sampling. Sample rates up to (2^31 - 1) are supported.
InstallSignalHandlers	true	Install GWP-ASan signal handlers for SIGSEGV during dynamic loading. This allows better error reports by providing stack traces for allocation and deallocation when reporting a memory error. GWP-ASan’s signal handler will forward the signal to any previously-installed handler, and user programs that install further signal handlers should make sure they do the same. Note, if the previously installed SIGSEGV handler is SIG_IGN, we terminate the process after dumping the error report.

Example ¶

The below code has a use-after-free bug, where the string_view is created as a reference to the temporary result of the string+ operator. The use-after-free occurs when sv is dereferenced on line 8.

#include <iostream>
#include <string>
#include <string_view>

int main() {
  std::string s = "Hellooooooooooooooo ";
  std::string_view sv = s + "World\n";
  std::cout << sv;
}

Compiling this code with Scudo+GWP-ASan will probabilistically catch this bug and provide us a detailed error report:

$ clang++ -fsanitize=scudo -std=c++17 -g buggy_code.cpp
$ for i in `seq 1 200`; do
    GWP_ASAN_OPTIONS="SampleRate=100" ./a.out > /dev/null;
  done
|
| *** GWP-ASan detected a memory error ***
| Use after free at 0x7feccab26000 (0 bytes into a 41-byte allocation at 0x7feccab26000) by thread 31027 here:
|   ...
|   #9 ./a.out(_ZStlsIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_St17basic_string_viewIS3_S4_E+0x45) [0x55585c0afa55]
|   #10 ./a.out(main+0x9f) [0x55585c0af7cf]
|   #11 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fecc966952b]
|   #12 ./a.out(_start+0x2a) [0x55585c0867ba]
|
| 0x7feccab26000 was deallocated by thread 31027 here:
|   ...
|   #7 ./a.out(main+0x83) [0x55585c0af7b3]
|   #8 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fecc966952b]
|   #9 ./a.out(_start+0x2a) [0x55585c0867ba]
|
| 0x7feccab26000 was allocated by thread 31027 here:
|   ...
|   #12 ./a.out(main+0x57) [0x55585c0af787]
|   #13 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fecc966952b]
|   #14 ./a.out(_start+0x2a) [0x55585c0867ba]
|
| *** End GWP-ASan report ***
| Segmentation fault

To symbolize these stack traces, some care has to be taken. Scudo currently uses GNU’s backtrace_symbols() from <execinfo.h> to unwind. The unwinder provides human-readable stack traces in function+offset form, rather than the normal binary+offset form. In order to use addr2line or similar tools to recover the exact line number, we must convert the function+offset to binary+offset. A helper script is available at compiler-rt/lib/gwp_asan/scripts/symbolize.sh. Using this script will attempt to symbolize each possible line, falling back to the previous output if anything fails. This results in the following output:

$ cat my_gwp_asan_error.txt | symbolize.sh
|
| *** GWP-ASan detected a memory error ***
| Use after free at 0x7feccab26000 (0 bytes into a 41-byte allocation at 0x7feccab26000) by thread 31027 here:
| ...
| #9 /usr/lib/gcc/x86_64-linux-gnu/8.0.1/../../../../include/c++/8.0.1/string_view:547
| #10 /tmp/buggy_code.cpp:8
|
| 0x7feccab26000 was deallocated by thread 31027 here:
| ...
| #7 /tmp/buggy_code.cpp:8
| #8 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fecc966952b]
| #9 ./a.out(_start+0x2a) [0x55585c0867ba]
|
| 0x7feccab26000 was allocated by thread 31027 here:
| ...
| #12 /tmp/buggy_code.cpp:7
| #13 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fecc966952b]
| #14 ./a.out(_start+0x2a) [0x55585c0867ba]
|
| *** End GWP-ASan report ***
| Segmentation fault

Documentation

Getting Involved

Additional Links

This Page