The rustc compiler contains support for following sanitizers:
- AddressSanitizer a faster memory error detector. Can detect out-of-bounds access to heap, stack, and globals, use after free, use after return, double free, invalid free, memory leaks.
- ControlFlowIntegrity LLVM Control Flow Integrity (CFI) provides forward-edge control flow protection.
- Hardware-assisted AddressSanitizer a tool similar to AddressSanitizer but based on partial hardware assistance.
- KernelControlFlowIntegrity LLVM Kernel Control Flow Integrity (KCFI) provides forward-edge control flow protection for operating systems kernels.
- LeakSanitizer a run-time memory leak detector.
- MemorySanitizer a detector of uninitialized reads.
- ThreadSanitizer a fast data race detector.
How to use the sanitizers?
To enable a sanitizer compile with
-Z sanitizer=... option, where value is one
thread. For more
details on how to use sanitizers please refer to the sanitizer flag in the
How are sanitizers implemented in rustc?
The implementation of sanitizers (except CFI) relies almost entirely on LLVM. The rustc is an integration point for LLVM compile time instrumentation passes and runtime libraries. Highlight of the most important aspects of the implementation:
The sanitizer runtime libraries are part of the compiler-rt project, and will be built on supported targets when enabled in
[build] sanitizers = true
The runtimes are placed into target libdir.
During LLVM code generation, the functions intended for instrumentation are marked with appropriate LLVM attribute:
SanitizeThread. By default all functions are instrumented, but this behaviour can be changed with
The decision whether to perform instrumentation or not is possible only at a function granularity. In the cases were those decision differ between functions it might be necessary to inhibit inlining, both at MIR level and LLVM level.
The LLVM IR generated by rustc is instrumented by dedicated LLVM passes, different for each sanitizer. Instrumentation passes are invoked after optimization passes.
When producing an executable, the sanitizer specific runtime library is linked in. The libraries are searched for in the target libdir. First relative to the overridden system root and subsequently relative to the default system root. Fall-back to the default system root ensures that sanitizer runtimes remain available when using sysroot overrides constructed by cargo
-Z build-stdor xargo.
Sanitizers are validated by code generation tests in
tests/codegen/sanitize*.rs and end-to-end functional tests in
Testing sanitizer functionality requires the sanitizer runtimes (built when
sanitizer = true in
config.toml) and target providing support for particular
sanitizer. When sanitizer is unsupported on given target, sanitizers tests will
be ignored. This behaviour is controlled by compiletest
Enabling sanitizer on a new target
To enable a sanitizer on a new target which is already supported by LLVM:
- Include the sanitizer in the list of
supported_sanitizersin the target definition.
rustc --target .. -Zsanitizer=..should now recognize sanitizer as supported.
- Build the runtime for the target and include it in the libdir.
- Teach compiletest that your target now supports the sanitizer.
Tests marked with
needs-sanitizer-*should now run on the target.
- Run tests
./x.py test --force-rerun tests/ui/sanitize/to verify.
- --enable-sanitizers in the CI configuration to build and distribute the sanitizer runtime as part of the release process.