sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets

[rcvalle]

Add support for specifying stable sanitizers in addition to the existing supported sanitizers, remove the -Zsanitizer unstable option and have only the -Csanitize codegen option, requiring the -Zunstable-options to be passed for using unstable sanitizers, add AddressSanitizer and LeakSanitizer for the Tier 1 targets that support them, and also stabilize the no_sanitize attribute so stable sanitizers can also be selectively disabled for annotated functions.. The tracking issue for stabilizing the sanitizers is #123615. This is part of our work to stabilize support for sanitizers in the Rust compiler. (See our roadmap at https://hackmd.io/@rcvalle/S1Ou9K6H6.)

Stabilization Report

Summary

We would like to propose stabilizing AddressSanitizer and LeakSanitizer for the Tier 1 targets that support them, and stabilize the no_sanitize attribute so stable sanitizers can also be selectively disabled for annotated functions.. This will be done by

• Add support for specifying stable sanitizers in addition to the existing supported sanitizers.
• Removing the -Zsanitizer unstable option and having only the -Csanitize codegen option, and requiring the -Zunstable-options to be passed for using unstable sanitizers.
• Adding these sanitizers to the stable sanitizers.
• Stabilize the no_sanitize attribute.

After stabilizing these sanitizers, the supported sanitizers will look like this:

Target	Supported Sanitizers (Stable)	Supported Sanitizers (Unstable)
aarch64-apple-darwin	address	cfi, thread
aarch64-apple-ios		address, thread
aarch64-apple-ios-macabi		address, leak, thread
aarch64-apple-ios-sim		address, thread
aarch64-apple-visionos		address, thread
aarch64-apple-visionos-sim		address, thread
aarch64-linux-android		address, cfi, hwaddress, memtag, shadow-call-stack
aarch64-unknown-freebsd		address, cfi, memory, thread
aarch64-unknown-fuchsia		address, cfi, shadow-call-stack
aarch64-unknown-illumos		address, cfi
aarch64-unknown-linux-gnu	address, leak	cfi, hwaddress, kcfi, memory, memtag, thread
aarch64-unknown-linux-musl		address, cfi, leak, memory, thread
aarch64-unknown-linux-ohos		address, cfi, hwaddress, leak, memory, memtag, thread
aarch64-unknown-none		kcfi, kernel-address
arm-linux-androideabi		address
arm64e-apple-darwin		address, cfi, thread
arm64e-apple-ios		address, thread
armv7-linux-androideabi		address
i586-pc-windows-msvc	address
i586-unknown-linux-gnu	address
i686-linux-android		address
i686-pc-windows-msvc	address
i686-unknown-linux-gnu	address
loongarch64-unknown-linux-gnu		address, cfi, leak, memory, thread
loongarch64-unknown-linux-musl		address, cfi, leak, memory, thread
loongarch64-unknown-linux-ohos		address, cfi, leak, memory, thread
riscv64-linux-android		address
riscv64gc-unknown-fuchsia		shadow-call-stack
riscv64gc-unknown-none-elf		kernel-address, shadow-call-stack
riscv64gc-unknown-nuttx-elf		kernel-address
riscv64imac-unknown-none-elf		kernel-address, shadow-call-stack
riscv64imac-unknown-nuttx-elf		kernel-address
s390x-unknown-linux-gnu		address, leak, memory, thread
s390x-unknown-linux-musl		address, leak, memory, thread
thumbv7neon-linux-androideabi		address
x86_64-apple-darwin	address, leak	cfi, thread
x86_64-apple-ios		address, thread
x86_64-apple-ios-macabi		address, leak, thread
x86_64-linux-android		address
x86_64-pc-solaris		address, cfi, thread
x86_64-pc-windows-msvc	address
x86_64-unknown-freebsd		address, cfi, memory, thread
x86_64-unknown-fuchsia		address, cfi, leak
x86_64-unknown-illumos		address, cfi, thread
x86_64-unknown-linux-gnu	address, leak	cfi, dataflow, kcfi, memory, safestack, thread
x86_64-unknown-linux-musl		address, cfi, leak, memory, thread
x86_64-unknown-linux-ohos		address, cfi, leak, memory, thread
x86_64-unknown-netbsd		address, cfi, leak, memory, thread
x86_64-unknown-none		kcfi, kernel-address
x86_64h-apple-darwin		address, cfi, leak, thread

The tracking issue for stabilizing the sanitizers is #123615. This is part of our work to stabilize support for sanitizers in the Rust compiler. (See our roadmap at https://hackmd.io/@rcvalle/S1Ou9K6H6.)

Documentation

Documentation will be updated by adding documentation for the -Csanitizer codegen option to the Codegen Options in the The rustc book.

Tests

You may find current and will find additional test cases for the sanitizers in:

• tests/ui/sanitizer
• tests/codegen/sanitizer

Unresolved questions

• Doesn't the sanitizers require rebuilding the Rust Standard Library (i.e., Cargo build-std feature)?
  We will prioritize stabilizing sanitizers that provide incremental value without requiring rebuilding the Rust Standard Library (i.e., Cargo build-std feature). We're also working on Partial compilation using MIR-only rlibs compiler-team#738, which should help with -Zbuild-std.

[rustbot]

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

These commits modify compiler targets.
(See the Target Tier Policy.)

[rcvalle]

r? @davidtwco

[compiler-errors]

I'd like to see tests that exercise things like -Csanitizer=non-existent and -Zsanitizer=non-existent, and also -Zsanitizer=stable-sanitizer¹ (e.g. an x86_64-unknown-linux-gnu test for a stable sanitizer) and -Csanitizer=unstable-sanitizer (I believe you can add a run-make test with a custom target that has no sanitizers enabled for it?)

Footnotes

1. What do we do if we pass -Zsanitizer with a stable sanitizer? Should we error? Presumably not, but I would assume we'd want to at least warn the users that the sanitizer has been stabilized and they should be using -C, just like we do for feature gates. ↩

[tgross35]

Documentation will need an update. Is something like -Csanitizer=address,memory expected to work (like LLVM) ordoes it need to be -Csanitizer=address -Dsanitizer=memory?

[Noratrieb]

This is unusable to most stable Rust users, right? It requires either -Zbuild-std or a custom toolchain with an instrumented standard library. The documentation in the rustc book and the stabilization report/description (which you need to add) should mention this very clearly.

[rustbot]

Some changes occurred in cfg and check-cfg configuration

cc @Urgau

Some changes occurred in tests/ui/sanitizer

cc @rust-lang/project-exploit-mitigations, @rcvalle

Some changes occurred in tests/codegen/sanitizer

cc @rust-lang/project-exploit-mitigations, @rcvalle

[glandium]

-Clinker-plugin-lto is another flag that is specific to LLVM.

[rcvalle]

Thank you everyone again for the patience and the time while I went through all the issues listed here. Here are the final updates about these issues:

• possible ASAN miscompile #121028 was fixed in Use the aligned size for alloca at args/ret when the pass mode is cast #127168 and the fix is being followed up on Use insertvalue and extractvalue instead of memcpy in CastTarget #128969.
• Incompatible ASan runtimes when Rust executable links with C shared library that dynamic links asan runtime #114127 was fixed in Add -Z external-clangrt #121207
  Previously, this had to be worked around by providing empty archives so the hard coded paths passed to the linker did not cause an error and additional archives with the actual runtime libraries could be provided. Thus, preventing the hard coded paths from being passed to the linker seems the right fix to me.
• Unable to link use of hyper_util with -Zsanitizer=address on msvc #124390 was fixed in PassWrapper: disable UseOdrIndicator for Asan Win32 #132773.
• Address sanitiser fails to link on x86_64-apple-darwin nightly toolchain #99428 is not a bug.
• AddressSanitizer detects a stack-use-after-scope in Chain::new when optimizations are enabled #98454 seems to be a bug on LLVM. I don't think we should block stabilization on this, but let me know if any of you think otherwise.
• ASan/MSan should call __sanitizer_unaligned_{load,store} functions when performing unaligned reads/writes (TSan already calls equivalents) #81722 is not a bug.
• tests/ui/sanitize/leak.rs fails on Linux with sanitizers = true #111073 was fixed in LLVM in [lsan] Fix free(NULL) interception during initialization llvm/llvm-project#106912.

I also added AddressSanitizer for aarch64-apple-darwin since it was promoted to Tier 1 in #128592, but let me know if anyone has any objections. Otherwise, this PR should be ready to be merged.

Thank you to everyone that contributed to and in this PR! Also thank you very much for helping me out with pushing this through the last mile, @tmiasko, @1c3t3a, and @jakos-sec! It was much appreciated.

[bors]

☔ The latest upstream changes (presumably #134516) made this pull request unmergeable. Please resolve the merge conflicts.

[jieyouxu]

Suggestion: since this is renaming that particular sanitizer directive, could you please update https://rustc-dev-guide.rust-lang.org/tests/directives.html#controlling-when-tests-are-run (repo is https://github.com/rust-lang/rustc-dev-guide) about this particular rename? I think the current needs-sanitizer-* docs are already somewhat outdated but yeah.