-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sanitizers: Stabilize AddressSanitizer and LeakSanitizer for the Tier 1 targets #123617
base: master
Are you sure you want to change the base?
Conversation
rustbot has assigned @compiler-errors. Use |
Some changes occurred in src/tools/compiletest cc @jieyouxu These commits modify compiler targets. |
r? @davidtwco |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like to see tests that exercise things like -Csanitizer=non-existent
and -Zsanitizer=non-existent
, and also -Zsanitizer=stable-sanitizer
1 (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
-
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. ↩
Documentation will need an update. Is something like |
This is unusable to most stable Rust users, right? It requires either |
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
cec660e
to
17eff53
Compare
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
17eff53
to
f81f25d
Compare
This comment has been minimized.
This comment has been minimized.
f81f25d
to
2cfed6e
Compare
☔ The latest upstream changes (presumably #127216) made this pull request unmergeable. Please resolve the merge conflicts. |
As far existing bug reports are concerned, for LeakSanitizer we also have #111073. Without replicating clang I expected we would stabilize this under |
The proposed removal of It is infeasible for the tooling to keep track of which sanitizers are stabilized for which target in which compiler version, so the new CLI must avoid requiring that. I understand that the following algorithm would be sufficient for enabling sanitizers across both previous and future compiler versions: Parse the output of @rcvalle is that correct? If so, I'll make a draft PR for |
I've implemented support for the proposed new CLI in It took about ~100 LoC, not counting tests. This will not support a range of nightly rustc versions on which the version number is set to the one in which the sanitizers are set to stabilize, but this PR is not yet merged. Allowing both |
It's up to the compiler team to decide, but I think this would be rather atypical for an unstable flag. |
I'm not sure if formal FCP concerns are still open, but I want to raise #127483 regarding global variables. That PR is now adding instrumentation to globals unless they opt out with |
Regarding what @Shnatsel mentioned: for the Linux kernel, we also have to decide which flag(s) to use depending on the version/architecture/configuration, so it would be nice to make it as simple as possible. Relatedly, one thing we do in the C side (and for other tools too) is to try to compile a dummy file to see if a given compiler supports an option -- it would be nice to have a convenient/proper way to test for that instead. (We also do version testing, e.g. >= 1.79.0). |
As a dumb little stopgap, I could imagine And it wouldn't be too difficult to eventually remove this hack once the attribute is stable. It's just a few crates that have to be changed, |
Thank you everyone for the patience and the time while I go through all the issues listed here. One of the things that has been mentioned on the tracking issue for stabilizing the sanitizers (#123615) is the absence of Rust interfaces and FFI bindings for the sanitizers (user) interfaces, so I've been working on this for the past few days and have an early/draft implementation of a create that provides (safe) interfaces and FFI bindings for the sanitizers (user) interfaces (see https://crates.io/crates/sanitizers and https://github.com/rcvalle/rust-crate-sanitizers). It currently reflects the current state of the sanitizers interfaces API and documentation, and I think the crate and the sanitizers interfaces themselves in LLVM would benefit from some standardization of their API and documentation, and is something I'd like to improve in the future. Any contributions are greatly appreciated! Regarding stabilizing the sanitizers under Regarding the removal of |
I think it also makes sense to include the stabilization of the |
Keeping only a
I'm open to this, it's just that there seemed to be more open design questions about the attribute. |
8ea55cc
to
e556716
Compare
This comment has been minimized.
This comment has been minimized.
e556716
to
b94f5bc
Compare
This comment has been minimized.
This comment has been minimized.
b94f5bc
to
6e56e6b
Compare
Some changes occurred in src/doc/unstable-book/src/language-features/no-sanitize.md cc @rust-lang/project-exploit-mitigations, @rcvalle |
This comment has been minimized.
This comment has been minimized.
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.
Stabilize the `no_sanitize` attribute so stable sanitizers can also be selectively disabled for annotated functions.
8b7530b
to
8af3b93
Compare
☔ The latest upstream changes (presumably #129046) made this pull request unmergeable. Please resolve the merge conflicts. |
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 theno_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-Zsanitizer
unstable option and having only the-Csanitize
codegen option, and requiring the-Zunstable-options
to be passed for using unstable sanitizers.no_sanitize
attribute.After stabilizing these sanitizers, the supported sanitizers will look like this:
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
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
.