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) or does 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

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

[bors]

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

[rcvalle]

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.

Yes, this summarizes well what we discussed there. For this PR, we could:

1. Drop the stabilization of the no_sanitize feature and do it separately later as discussed in this Zulip thread.
2. Do it as part of this PR the same as discussed in the Zulip thread above.

We would choose (1) if there are any concerns left we would like to discuss before implementing it. Otherwise, I think we could choose (2).

[rcvalle]

@1c3t3a Just implemented what was as discussed in the Zulip thread above in #142681 (we chatted and decided it was better to be submitted as a separated PR).

Thank you very much for your time and work on this, @1c3t3a! Much appreciated. I'll resolve the merge conflicts on this PR and remove the commit that would stabilize the no_sanitize attribute, and once both PRs are ready and approved we can merge them together.

[rcvalle]

I've resolved the merge conflicts on this PR and removed the commit that would stabilize the no_sanitize attribute in favor of #142681. @traviscross @wesleywiser whenever you have time, let me know if these PRs look good to you and/or if there are any pending concerns.

[rcvalle]

@rustbot ready

[bors]

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

[ehuss]

Do we want to say something about the stability of these sanitizers? For example, I assume we want to have the flexibility to ship a future version of Rust where they were removed?

[jieyouxu]

Question (forcing inline comment): cf #143561 what's the intended sanitizer support under cross-compile scenarios? As far as I can tell, on {i686,x86_64}-pc-windows-msvc, ASAN requires Microsoft-provided runtimes that bootstrap tries to detect based on a cl.exe directory traversal. Implementation assumptions aside, what's intended to happen if a user tries to target {i686,x86_64}-pc-windows-msvc on say x86_64-unknown-linux-gnu host with e.g. ASAN enabled? I assume cross-compile is not a generally supported use case, right? I assume for LLVM-supported ASAN we could ship those too for the target, so cross-compile might work.

[apiraino]

Checking status here, I think there are some open questions to be addressed

@rustbot author

[rcvalle]

Sorry for the delay on this--I have been busy the past few months. I resumed working on this, and I'm currently going through the merge conflicts caused by #142681 and #138736, and should have them resolved along with the pending comments for review in the next few days.

[rustbot]

compiletest directives have been modified. Please add or update docs for the
new or modified directive in src/doc/rustc-dev-guide/.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-log-analyzer]

The job aarch64-gnu-llvm-20-2 failed! Check out the build log: (web) (plain enhanced) (plain)

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

---- spec::tests::aarch64_apple_darwin stdout ----

thread 'spec::tests::aarch64_apple_darwin' (54868) panicked at compiler/rustc_target/src/spec/mod.rs:3301:9:
assertion `left == right` failed
  left: Err("stable-sanitizers: unknown field `stable-sanitizers`, expected one of `llvm-target`, `target-pointer-width`, `data-layout`, `arch`, `metadata`, `target-endian`, `frame-pointer`, `target-c-int-width`, `c-enum-min-bits`, `os`, `env`, `abi`, `vendor`, `linker`, `linker-flavor`, `lld-flavor`, `linker-is-gnu`, `pre-link-objects`, `post-link-objects`, `pre-link-objects-fallback`, `post-link-objects-fallback`, `crt-objects-fallback`, `link-self-contained`, `pre-link-args`, `late-link-args`, `late-link-args-dynamic`, `late-link-args-static`, `post-link-args`, `link-script`, `link-env`, `link-env-remove`, `asm-args`, `cpu`, `need-explicit-cpu`, `features`, `dynamic-linking`, `direct-access-external-data`, `dll-tls-export`, `only-cdylib`, `executables`, `relocation-model`, `code-model`, `tls-model`, `disable-redzone`, `function-sections`, `dll-prefix`, `dll-suffix`, `exe-suffix`, `staticlib-prefix`, `staticlib-suffix`, `target-family`, `abi-return-struct-as-int`, `is-like-aix`, `is-like-darwin`, `is-like-solaris`, `is-like-windows`, `is-like-gpu`, `is-like-msvc`, `is-like-wasm`, `is-like-android`, `is-like-vexos`, `binary-format`, `default-dwarf-version`, `allows-weak-linkage`, `has-rpath`, `no-default-libraries`, `position-independent-executables`, `static-position-independent-executables`, `plt-by-default`, `relro-level`, `archive-format`, `allow-asm`, `main-needs-argc-argv`, `has-thread-local`, `obj-is-bitcode`, `max-atomic-width`, `min-atomic-width`, `atomic-cas`, `panic-strategy`, `crt-static-allows-dylibs`, `crt-static-default`, `crt-static-respected`, `stack-probes`, `min-global-align`, `default-codegen-units`, `default-codegen-backend`, `trap-unreachable`, `requires-lto`, `singlethread`, `no-builtins`, `default-visibility`, `emit-debug-gdb-scripts`, `requires-uwtable`, `default-uwtable`, `simd-types-indirect`, `limit-rdylib-exports`, `override-export-symbols`, `merge-functions`, `target-mcount`, `llvm-mcount-intrinsic`, `llvm-abiname`, `llvm-floatabi`, `rustc-abi`, `relax-elf-relocations`, `llvm-args`, `use-ctors-section`, `eh-frame-header`, `has-thumb-interworking`, `debuginfo-kind`, `split-debuginfo`, `supported-split-debuginfo`, `supported-sanitizers`, `default-sanitizers`, `generate-arange-section`, `supports-stack-protector`, `small-data-threshold-support`, `entry-name`, `supports-xray`, `entry-abi` at line 1 column 927")

[rust-bors]

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