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

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

[bors]

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

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[rustbot]

triagebot.toml has been modified, there may have been changes to the review queue.

cc @davidtwco, @wesleywiser

[bors]

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

[rust-log-analyzer]

The job x86_64-gnu-llvm-19 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

Runner name: 'ubuntu-24.04-16core-64gb_728cf5c5b1be'
Runner group name: 'Default Larger Runners'
Machine name: 'pkrvmberfyhpb9w'
##[group]Operating System
Ubuntu
24.04.2
LTS
##[endgroup]
---
#18 exporting to docker image format
#18 sending tarball 20.5s done
#18 DONE 26.9s
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-19]
[CI_JOB_NAME=x86_64-gnu-llvm-19]
debug: `DISABLE_CI_RUSTC_IF_INCOMPATIBLE` configured.
---
sccache: Listening on address 127.0.0.1:4226
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-19', '--enable-llvm-link-shared', '--set', 'rust.randomize-layout=true', '--set', 'rust.thin-lto-import-instr-limit=10', '--set', 'build.print-step-timings', '--enable-verbose-tests', '--set', 'build.metrics', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--set', 'rust.lld=false', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--set', 'gcc.download-ci-gcc=true', '--enable-new-symbol-mangling']
configure: build.build          := x86_64-unknown-linux-gnu
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-19/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.randomize-layout := True
configure: rust.thin-lto-import-instr-limit := 10
---
diff of stderr:

60    | ------------------------- not a function
61 
62 error: `#[no_sanitize(...)]` should be applied to a function
-   --> $DIR/no-sanitize.rs:42:15
+   --> $DIR/no-sanitize.rs:41:15
64    |
65 LL | #[no_sanitize("address")]
66    |               ^^^^^^^^^
---
To only update this specific test, also pass `--test-args attributes/no-sanitize.rs`

error: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/attributes/no-sanitize.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--target=x86_64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "--emit" "metadata" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/attributes/no-sanitize" "-A" "unused" "-A" "internal_features" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
stdout: none
--- stderr -------------------------------
error: `#[no_sanitize(memory)]` should be applied to a function
##[error]  --> /checkout/tests/ui/attributes/no-sanitize.rs:6:19
   |
LL |       #[no_sanitize(memory)] //~ ERROR `#[no_sanitize(memory)]` should be applied to a function
   |                     ^^^^^^
LL | /     {
LL | |         1
LL | |     };
   | |_____- not a function

error: `#[no_sanitize(memory)]` should be applied to a function
##[error]  --> /checkout/tests/ui/attributes/no-sanitize.rs:12:15
   |
LL | #[no_sanitize(memory)] //~ ERROR `#[no_sanitize(memory)]` should be applied to a function
   |               ^^^^^^
LL | type InvalidTy = ();
   | -------------------- not a function

error: `#[no_sanitize(memory)]` should be applied to a function
##[error]  --> /checkout/tests/ui/attributes/no-sanitize.rs:15:15
   |
LL | #[no_sanitize(memory)] //~ ERROR `#[no_sanitize(memory)]` should be applied to a function
   |               ^^^^^^
LL | mod invalid_module {}
   | --------------------- not a function

error: `#[no_sanitize(memory)]` should be applied to a function
##[error]  --> /checkout/tests/ui/attributes/no-sanitize.rs:19:27
   |
LL |     let _ = #[no_sanitize(memory)] //~ ERROR `#[no_sanitize(memory)]` should be applied to a function
   |                           ^^^^^^
LL |     (|| 1);
   |     ------ not a function

error: `#[no_sanitize(memory)]` should be applied to a function
##[error]  --> /checkout/tests/ui/attributes/no-sanitize.rs:23:15
   |
LL | #[no_sanitize(memory)] //~ ERROR `#[no_sanitize(memory)]` should be applied to a function
   |               ^^^^^^
LL | struct F;
   | --------- not a function

error: `#[no_sanitize(memory)]` should be applied to a function
##[error]  --> /checkout/tests/ui/attributes/no-sanitize.rs:26:15
   |
LL |   #[no_sanitize(memory)] //~ ERROR `#[no_sanitize(memory)]` should be applied to a function
   |                 ^^^^^^
LL | / impl F {
LL | |     #[no_sanitize(memory)]
LL | |     fn valid(&self) {}
LL | | }
   | |_- not a function

error: `#[no_sanitize(memory)]` should be applied to a function
##[error]  --> /checkout/tests/ui/attributes/no-sanitize.rs:32:24
   |
LL | #[no_sanitize(address, memory)] //~ ERROR `#[no_sanitize(memory)]` should be applied to a function
   |                        ^^^^^^
LL | static INVALID : i32 = 0;
   | ------------------------- not a function

error: `#[no_sanitize(...)]` should be applied to a function
##[error]  --> /checkout/tests/ui/attributes/no-sanitize.rs:41:15
   |
LL | #[no_sanitize("address")]
   |               ^^^^^^^^^
...
---
   |
LL | #[no_sanitize("address")]
   |               ^^^^^^^^^
   |
   = note: expected one of: `address`, `cfi`, `hwaddress`, `kcfi`, `memory`, `memtag`, `shadow-call-stack`, or `thread`

error: aborting due to 9 previous errors
------------------------------------------

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting.

We were generally supportive of #[sanitize(off)]—and we felt we'd be more likely to call it that than #[no_sanitize] or similar—but we shared the concern raised here about the safety of the case where something with sanitize(off) calls something without sanitize(off). In C, the compiler doesn't give any help with this; it's the usual "make sure you do this correctly or it'll explode".

That seems like a footgun. And one you're more likely to hit in Rust than in C, because of the wide variety of helper methods like those on Option or Result.

We weren't sure what the right footgun-free way to handle turning off sanitizers would be, though.

Also, separately from that concern, if we want to support turning off individual sanitizers, the possible syntax sanitize(-onesanitizername) came up. But that does have the same safety problem as sanitize(off).

In any case, please do include T-lang on any FCP that includes any attributes. (An FCP that just enables sanitizers in the compiler but doesn't add any attributes or other language surface area doesn't need any T-lang approval, of course.)

[traviscross]

We ended up discussing this further today in the lang/RfL call. There, a couple of points were made.

One was that the kernel doesn't actually use #[sanitize(off)] any longer. It was needed at one point, because of a bug in the sanitizer, but that's since been fixed. It was generally felt that any place this would be needed might be a bug in the sanitizer.

Two was that, even if one did need to turn off a sanitizer (e.g. for this reason), one would generally want to do it at the level of a compilation unit rather than at the level of an item.

Based on that, perhaps it would be better to just pull the attribute out of this stabilization entirely. Then, if there is some residual motivation for this, that can be presented and we can consider that, and the design of the attribute, separately.

CC @rcvalle @Darksonn, who might have additional details they could fill in here.

[ojeda]

It was needed at one point

I think that was referring to the formatting-related fix that happened in core, which is still there from a quick look. Since it is in core rather than the kernel side, in principle it wouldn't have needed the stabilization. By the way, it currently uses any(sanitize = "cfi", sanitize = "kcfi")).

[Darksonn]

One was that the kernel doesn't actually use #[sanitize(off)] any longer. It was needed at one point, because of a bug in the sanitizer, but that's since been fixed.

I think I was unclear here. The one use of #[no_sanitize] that we had is the one in core that was removed by #139632. So now there are no more uses of #[no_sanitize] in the kernel, though we do have a #[cfg()] on whether a sanitizer is enabled.

Two was that, even if one did need to turn off a sanitizer (e.g. for this reason), one would generally want to do it at the level of a compilation unit rather than at the level of an item.

To clarify, this is referring to the case where you are implementing the sanitizer runtime in Rust, since the sanitizer runtime itself is usually not sanitized. The use case that Rust had for #[no_sanitize] in core that we got rid of is a legitimate use of #[no_sanitize], however it's a case where you are legitimately calling into other functions where sanitization is off - i.e. warning on calls into sanitized code is not an error.

So to summarize, I meant to say that if you had a case where calling from non-sanitized into sanitized code was a problem, then you would probably be in a situation where you're turning it off the entire compilation unit anyway.