Tracking issue for sanitizer support

[japaric]

View all comments

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 LeakSanitizer, ThreadSanitizer, AddressSanitizer and MemorySanitizer support #38699.

• An attribute #[no_sanitize] to disable sanitization on specific functions. Also lints if those functions are marked as requesting inlining. Added in Selectively disable sanitizer instrumentation #68164.

  • #[no_sanitize] suppresses #[inline] hints. A lint is issued if combined with #[inline(always)].

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

  • ThreadSanitizer detects a data race in the test runner (rustc --test) 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) MemorySanitizer detects an use of unitialized value in the test runner (rustc --test) #39610

• Known issues

  • Incremental compilation breaks sanitizers Incremental compilation breaks sanitizers #39611

• Unresolved questions:

  • Should we call the attribute #[no_sanitize] or perhaps something like #[sanitize(never)] or some other variation? In particular, might we at some point want "positive options" like #[sanitize(miri(aggressive))]? There is much back and forth in Selectively disable sanitizer instrumentation #68164.
  • What should the user experience be to enable sanitizers, particularly when using cargo? Should cargo have first-class support? Is that blocked on build-std stabilizing?

[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@c8a8767c5), 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 (Build instruction profiler runtime as part of compiler-rt #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.