sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets #123617

rcvalle · 2024-04-08T03:25:39Z

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:

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 · 2024-04-08T03:25:48Z

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 · 2024-04-08T03:25:51Z

Some changes occurred in src/tools/compiletest

cc @jieyouxu

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

rcvalle · 2024-04-08T03:26:00Z

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?)

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

compiler/rustc_target/src/spec/mod.rs

compiler/rustc_session/src/options.rs

compiler/rustc_target/src/spec/mod.rs

tgross35 · 2024-04-08T18:13:38Z

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 · 2024-04-09T07:06:34Z

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 · 2024-04-23T02:49:40Z

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

jieyouxu · 2025-07-07T07:20:55Z

tests/ui/sanitizer/unsupported-target.stderr

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.

Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]` This came up during the sanitizer stabilization (#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)). The new attribute also works on modules, traits and impl items and thus enables usage as the following: ```rust #[sanitize(address = "off")] mod foo { fn unsanitized(..) {} #[sanitize(address = "on")] fn sanitized(..) {} } trait MyTrait { #[sanitize(address = "off")] fn unsanitized_default(..) {} } #[sanitize(thread = "off")] impl MyTrait for () { ... } ``` r? `@rcvalle`

Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]` This came up during the sanitizer stabilization (rust-lang#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)). The new attribute also works on modules, traits and impl items and thus enables usage as the following: ```rust #[sanitize(address = "off")] mod foo { fn unsanitized(..) {} #[sanitize(address = "on")] fn sanitized(..) {} } trait MyTrait { #[sanitize(address = "off")] fn unsanitized_default(..) {} } #[sanitize(thread = "off")] impl MyTrait for () { ... } ``` r? `@rcvalle`

Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]` This came up during the sanitizer stabilization (rust-lang#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)). The new attribute also works on modules, traits and impl items and thus enables usage as the following: ```rust #[sanitize(address = "off")] mod foo { fn unsanitized(..) {} #[sanitize(address = "on")] fn sanitized(..) {} } trait MyTrait { #[sanitize(address = "off")] fn unsanitized_default(..) {} } #[sanitize(thread = "off")] impl MyTrait for () { ... } ``` r? ``@rcvalle``

Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]` This came up during the sanitizer stabilization (rust-lang#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)). The new attribute also works on modules, traits and impl items and thus enables usage as the following: ```rust #[sanitize(address = "off")] mod foo { fn unsanitized(..) {} #[sanitize(address = "on")] fn sanitized(..) {} } trait MyTrait { #[sanitize(address = "off")] fn unsanitized_default(..) {} } #[sanitize(thread = "off")] impl MyTrait for () { ... } ``` r? ```@rcvalle```

Rollup merge of #142681 - 1c3t3a:sanitize-off-on, r=rcvalle Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]` This came up during the sanitizer stabilization (#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)). The new attribute also works on modules, traits and impl items and thus enables usage as the following: ```rust #[sanitize(address = "off")] mod foo { fn unsanitized(..) {} #[sanitize(address = "on")] fn sanitized(..) {} } trait MyTrait { #[sanitize(address = "off")] fn unsanitized_default(..) {} } #[sanitize(thread = "off")] impl MyTrait for () { ... } ``` r? ```@rcvalle```

Remove the `#[no_sanitize]` attribute in favor of `#[sanitize(xyz = "on|off")]` This came up during the sanitizer stabilization (rust-lang/rust#123617). Instead of a `#[no_sanitize(xyz)]` attribute, we would like to have a `#[sanitize(xyz = "on|off")]` attribute, which is more powerful and allows to be extended in the future (instead of just focusing on turning sanitizers off). The implementation is done according to what was [discussed on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/343119-project-exploit-mitigations/topic/Stabilize.20the.20.60no_sanitize.60.20attribute/with/495377292)). The new attribute also works on modules, traits and impl items and thus enables usage as the following: ```rust #[sanitize(address = "off")] mod foo { fn unsanitized(..) {} #[sanitize(address = "on")] fn sanitized(..) {} } trait MyTrait { #[sanitize(address = "off")] fn unsanitized_default(..) {} } #[sanitize(thread = "off")] impl MyTrait for () { ... } ``` r? ```@rcvalle```

apiraino · 2025-11-06T13:39:47Z

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

@rustbot author

rcvalle · 2025-11-07T20:12:12Z

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 · 2025-11-10T19:59:48Z

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

rustbot · 2025-12-09T21:47:10Z

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.

Add suppport for specifying stable sanitizers in addition to the existing supported sanitizers.

Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets that support them.

rust-log-analyzer · 2025-12-12T05:10:53Z

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")

rustbot assigned compiler-errors Apr 8, 2024

rustbot assigned davidtwco and unassigned compiler-errors Apr 8, 2024

rcvalle added the PG-exploit-mitigations Project group: Exploit mitigations label Apr 8, 2024

rcvalle mentioned this pull request Apr 8, 2024

Tracking Issue for stabilizing the sanitizers (e.g., AddressSanitizer, LeakSanitizer, MemorySanitizer, ThreadSanitizer) #123615

Open

3 tasks