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

[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.

[rcvalle]

I don't see any references to needs-sanitizer-kasan there (or just kasan). Mind pointing out where it needs to be updated?

[traviscross]

@rfcbot fcp cancel // The bot will ignore me.
@rustbot labels +I-lang-nominated +T-lang

• Stabilize the no_sanitize attribute.

Lang owns attributes, so this proposed FCP will need to include lang.

I wouldn't yet repropose FCP, because I don't see immediately if or where we've ever discussed this matter, and we may want to consider other spellings. E.g., @ehuss proposed #[sanitize(off)] to be consistent with what we intend to do with #[coverage(off)].

When we do repropose FCP, we can check the boxes checked here:

• sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets #123617 (comment)

And we'll also need to refile @wesleywiser's concern from here:

• sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets #123617 (comment)

[rcvalle]

@rfcbot fcp cancel // The bot will ignore me. @rustbot labels +I-lang-nominated +T-lang

• Stabilize the no_sanitize attribute.

Lang owns attributes, so this proposed FCP will need to include lang.

I wouldn't yet repropose FCP, because I don't see immediately if or where we've ever discussed this matter, and we may want to consider other spellings. E.g., @ehuss proposed #[sanitize(off)] to be consistent with what we intend to do with #[coverage(off)].

When we do repropose FCP, we can check the boxes checked here:

• sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets #123617 (comment)

And we'll also need to refile @wesleywiser's concern from here:

• sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets #123617 (comment)

Thanks for pointing it out! I've created a Zulip thread for us to discuss the next steps and stabilizing the no_sanitize attribute.

[rcvalle]

I'll add the comment here as well for completeness, but let's continue the discussion on the Zulip thread I created:

My main concern with #[sanitize(off)] is instrumenting functions recursively according to the possible call graph and solving the problem of indirect and virtual calls. I'm okay with renaming to maintain consistency (although no_sanitize is consistent with Clang/LLVM), but changing the semantics is the main concern for me.