Tracking issue for sanitizer support

[japaric]

Currently we have:

• A rustc flag, -Z sanitizer, to sanitize rlibs (it adds an extra LLVM pass/attribute) and executables (it links to the sanitizer runtime). Added in #38699.

• A few violations (false positives?) in the test runner

  • ThreadSanitizer detects a data race in the test runner (rustc --test) #39608
  • MemorySanitizer detects an use of unitialized value in the test runner (rustc --test) #39610

• Known issues

  • Incremental compilation breaks sanitizers #39611

Things that we may want to add:

• Some way to whitelist functions (an attribute?) to prevent false positives. This requires a RFC because it's an user facing change (users would have to modify the source code of their crates)

[kennytm]

Just for record. Currently only 4 sanitizers are enabled (asan, lsan, msan, tsan), and only in x86_64-unknown-linux-gnu (#38699) and x86_64-apple-darwin (#41352).

As of the LLVM 4.0 merge (rust-lang/compiler-rt@c8a8767), compiler-rt actually supports much more targets than rustc do, and also some additional sanitizers (e.g. esan) can be enabled in the future.

Architecture	x86	x86_64	ppc64	arm32	arm64	mips32	mips64	s390x
asan	✓	✓	✓	✓	✓	✓	✓	✓
dfsan		✓			✓		✓
lsan		✓			✓		✓
msan		✓	✓		✓		✓
tsan		✓	✓		✓		✓
ubsan	✓	✓	✓	✓	✓	✓	✓	✓
esan		✓					✓
cfi	✓	✓					✓
profile	✓	✓	✓	✓	✓	✓	✓	✓
safestack	✓	✓			✓	✓	✓
scudo	✓	✓		✓
xray		✓		✓	✓

Platform	linux	android	darwin & ios	windows-msvc	freebsd
asan	✓	✓	✓	✓	✓
dfsan	✓
lsan	✓				✓
msan	✓
tsan	✓		✓		✓
ubsan	✓		✓	✓	✓
esan	✓
cfi	✓
profile	✓		✓	✓	✓
safestack	✓		✓		✓
scudo	✓
xray	✓

• asan = AddressSanitizer
• dfsan = DataFlowSanitizer
• lsan = LeakSanitizer
• msan = MemorySanitizer
• tsan = ThreadSanitizer
• ubsan = UndefinedBehaviorSanitizer
• esan = EfficiencySanitizer (work in progress)
• cfi = Control Flow Integrity
• profile = Instrumentation profiler (#38608)
• safestack = SafeStack
• scudo = Scudo Hardened Allocator (useless for jemalloc)
• xray = XRay Instrumentation (requires LLVM attribute)

(not all of these are sanitizers, some of them are just tools or libraries that depend on the common sanitizer runtime)

[cuviper]

Is there any plan for stabilization here? Even if it remains x86_64-only for now, with only a few of the available sanitizers, it will still be quite useful to have. I have users that want this (rhbz1447423), but now that -Z is forbidden I want to wait for properly-supported sanitizer options.

[Firstyear]

Hi,

If I understand this issue, you would like to block certain -Z features from coming to stable rust. Sanitisers seems to be one of these. We have a very good use case for them though. When you have a C + Rust with FFI, and the C code is linked to libasan, the rust component will fail to link as it's missing libasan. For us it's important to get sanitisers into rust stable as we have an extensive C code based (that is well sanitised), and having this option available to us will help to determine if our Rust + C integration is behaving correctly.

I hope this helps explain our use case, as for us this is a blocker to our project adopting Rust today.

Thanks you!

[cuviper]

FWIW, it's not just certain -Z features, but -Z as a whole being blocked as unstable now.

[Firstyear]

#42711 PR for dylib asan support.

[Firstyear]

Hi,

I don't see any activity here. We really need this for our quality assurance workflow to be stabilised. What is outstanding and required for this to be made available in stable rustc?

Thanks!

[Firstyear]

Hi, sorry to bump this again, but @kennytm @aturon @japaric, would you be able to look at this and comment on why this is still blocked from being in "not-nightly"? We really need this support for our project to be able to adopt rust 100%.

Thanks,