Repository navigation
Tracking Issue for stabilizing the sanitizers (e.g., AddressSanitizer, LeakSanitizer, MemorySanitizer, ThreadSanitizer) #123615
Description
This is a tracking issue for stabilizing the sanitizers (e.g., AddressSanitizer, LeakSanitizer, MemorySanitizer, ThreadSanitizer). The original tracking issue for the sanitizers support for Rust is #39699. This is part of our work to organize and stabilize support for the sanitizers. (See our roadmap at https://hackmd.io/@rcvalle/S1Ou9K6H6.)
Steps
- Add support for separating sanitizers support in stable and unstable for supported targets.
- Stabilize AddressSanitizer and LeakSanitizer for Tier 1 targets.
- Create new Tier 2 targets with sanitizers enabled by default.
- Stabilize AddressSanitizer for the new Tier 2 targets.
- Stabilize MemorySanitizer and ThreadSanitizer for the new Tier 2 targets.
Unresolved Questions
Is there any concern or anything that the community would like to see implemented before their stabilization?
Implementation history
- sanitizers: Stabilize AddressSanitizer and LeakSanitizer #123617
- Propose a 2025H2 goal for sanitizer stabilization goals#337
- https://github.com/rust-lang/rust-project-goals/blob/main/src/2025h2/stabilization-of-sanitizer-support.md
- Stabilize MemorySanitizer and ThreadSanitizer Support goals#403
- https://github.com/rust-lang/rust-project-goals/blob/main/src/2026/stabilization-of-sanitizer-support.md
- Allow using prebuilt sanitizer libraries compiler-team#943
- Create new Tier 2 targets with sanitizers enabled by default compiler-team#951
- Create x86_64-unknown-linux-gnuasan target which enables ASAN by default #149644
- Add x86_64-unknown-linux-gnu{m,t}san target which enables {M,T}San by default #152757
Reacted by kamulos, Theo Paris, Marc-André Lureau, Zi How Poh, estaban, Cathal and Milan Raj
Activity
rcvalle commentedon Apr 8, 2024
@1c3t3a, @davidtwco, @jakos-sec, and I would like to propose initially stabilizing AddressSanitizer and LeakSanitizer for the Tier 1 targets that support them, and AddressSanitizer, LeakSanitizer, MemorySanitizer, and ThreadSanitizer for the new Tier 2 targets that provide a precompiled Rust Standard Library with the sanitizers enabled by default that we're also providing. After stabilizing these sanitizers, the supported sanitizers will look like this--we'll keep this supported sanitizers table updated as we stabilize the sanitizers:
Jules-Bertholet commentedon Apr 8, 2024
@rustbot label A-sanitizers
briansmith commentedon Jun 7, 2024
cfg(sanitizer = "known-but-unstable-sanitizer")should trigger a warning that can be disabled on non-Nightly Rust, instead of triggering the "use of an unstable feature". Otherwise crates that want to support stable Rust need to add feature flags or equivalent to guard their#[cfg(sanizier)]usage whenever they do something to support an unstable sanitizer.cfg(sanitizer = "unknown-sanitizer")should trigger a warning that can be disabled on non-Nightly Rust, for the same reason. Perhaps it should be a separate lint.briansmith commentedon Jun 7, 2024
__msan_unpoison, which is necessary for many things that skip libc and directly invoke syscalls, e.g. via inline assembly orlibc::syscallor equivalent. Similarly it is needed for inline assembly because MSAN (at least with Clang's inline assembly) quite reasonably doesn't track writes via inline assembly. Currently I just declare__msan_unpoisonasextern "C"and call it. Ideally there would be an official API for this.MaybeUninit::{assume_init, assume_init_drop, assume_init_mut, assume_init_ref, slice::{from_raw_parts,from_raw_parts_mut}will interact with msan? Note that these are all functions that serve to indicate that memory is readable/writable but don't actually read to the memory, so msan won't immediately trigger when they are called. However, I do think we should reserve the right for these functions to call__msan_check_mem_is_initialized, perhaps in some future opt-in or perhaps automatically. At a minimum, we need to document that callingassume_initand the like will NOT call__msan_unpoison.unsafe { &*ptr }andunsafe { &mut *p }) to immediately trigger msan via__msan_check_mem_is_initializedin the future, in some mode, perhaps the default?The above is specifically regarding MSAN but I guess analogous concerns for ASAN at least.
rcvalle commentedon Jul 18, 2024
Do you have an example of when it would be need that
#[cfg(sanitize = "sanitizer")]could not be used instead? If the sanitizer is not stable yet, it wouldn't be enabled and the code not compiled/evaluated by non-nightly builds of the compiler. Would it be for warning purposes only?rcvalle commentedon Jul 18, 2024
I've been working on this for the past few days and have an early/draft implementation of a create that provides (safe) interfaces and FFI bindings for the sanitizers interfaces (see https://crates.io/crates/sanitizers and https://github.com/rcvalle/rust-crate-sanitizers). It currently reflects the current state of the sanitizers interfaces API and documentation, and I think the crate and the sanitizers interfaces themselves would benefit from some standardization of their API and documentation and is something I'd like to improve in the future. Any contributions are greatly appreciated!
Thanks for pointing this out! I don't know the answer for this yet, but I think we could definitely reserve the right to (as you suggested) implement additional/specific checks for Rust in the future, similarly to how we could improve these sanitizers generally, and these would not be classified as breaking changes but improvements. What do you think?
rorth commentedon Aug 19, 2024
There are issues with the entry for
x86_64-pc-solaris(and alsox86_64-unknown-illumos):x86_64andsparcv9(the latter only with gcc, clang is buggy here).compiler-rt, but I read that rust cfi support doesn't requirelibclang_rt.cfi-*.a.config-ix.cmakeis irrelevant since whileCOMPILER_RT_TSAN_HAS_STATIC_RUNTIMEmay beTRUE(for whatever reason),COMPILER_RT_HAS_TSANis stillFALSE. To the best of my knowledge there's never been a tsan port to Solaris/Illumos; certainly there's none upstream.davidtwco commentedon Aug 21, 2024
I think what @briansmith is imagining is a scenario where a crate has cfgs for unstable sanitisers (which that crates supports on nightly), but because of those cfgs, the crate now has warnings on stable. On stable, these cfgs would never evaluate to
true, so it would be useful to be able to silence the "what is this sanitizer" warnings since you know it's just a yet-to-be-stabilized sanitizer.briansmith commentedon Aug 21, 2024
Exactly.
Detect use of MemorySanitizer without using Nightly-only features
Detect use of MemorySanitizer without using Nightly-only features
Detect use of MemorySanitizer without using Nightly-only features
Detect use of MemorySanitizer without using Nightly-only features (#571)
Detect use of MemorySanitizer without using Nightly-only features (ru…