-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Tracking issue for sanitizer support #39699
Comments
Just for record. Currently only 4 sanitizers are enabled (asan, lsan, msan, tsan), and only in As of the LLVM 4.0 merge (rust-lang/compiler-rt@c8a8767c5), compiler-rt actually supports much more targets than rustc do, and also some additional sanitizers (e.g. esan) can be enabled in the future.
(not all of these are sanitizers, some of them are just tools or libraries that depend on the common sanitizer runtime) |
Is there any plan for stabilization here? Even if it remains x86_64-only for now, with only a few of the available sanitizers, it will still be quite useful to have. I have users that want this (rhbz1447423), but now that -Z is forbidden I want to wait for properly-supported sanitizer options. |
Hi, If I understand this issue, you would like to block certain -Z features from coming to stable rust. Sanitisers seems to be one of these. We have a very good use case for them though. When you have a C + Rust with FFI, and the C code is linked to libasan, the rust component will fail to link as it's missing libasan. For us it's important to get sanitisers into rust stable as we have an extensive C code based (that is well sanitised), and having this option available to us will help to determine if our Rust + C integration is behaving correctly. I hope this helps explain our use case, as for us this is a blocker to our project adopting Rust today. Thanks you! |
FWIW, it's not just certain -Z features, but -Z as a whole being blocked as unstable now. |
#42711 PR for dylib asan support. |
Hi, I don't see any activity here. We really need this for our quality assurance workflow to be stabilised. What is outstanding and required for this to be made available in stable rustc? Thanks! |
Any updates on this? |
|
I'm interested in the XRay LLVM support; is this bug a sensible place to talk about that, or should I file a new bug, or an internals discussion ? |
The guide to rustc development now contains an overview of sanitizer implementation in rustc. It should be a good starting point for work on additional sanitizers or even XRay since there is a lot of common ground there. |
Hi, is there a way to access sanitizer interfaces, e.g., the A use case is when designing custom allocators based on Related: https://github.com/google/sanitizers/wiki/AddressSanitizerManualPoisoning |
On the naming of |
Are there any technical blockers that prevent this from "graduating" to stable? Rust is being used in more mixed language codebases, and with the merging of Rust support in the Linux kernel, I'd like to enable some of the kernel sanitizers (KCSAN, KASAN) for Rust code there eventually. This would improve the C bindings (if there are bugs) but also prove Rust's safety proposition quantitively (i.e. data showing fewer or no bugs found in Rust code). Thanks. |
Is there a separate issue tracking ASAN enlightenment for container types like LLVM's libc++ ASAN enlightenment for This issue isn't really unique to vectors either -- any container that over-allocates memory to reduce total number of allocations would be affected. |
The bad thing in my environment is the following. At my job I am developing a mixed Rust and C program built with Cargo. We already had a few ASAN findings slip into the main branch because during development ASAN is not used. I want to enforce, that every developer has ASAN active all the time and currently I only see the following options:
|
@kamulos I think this is getting a little off-topic, but can you set up a CI with a nightly compiler? I did this recently for Mio (using Github Action, but it should work anywhere) if you want a concrete example: https://github.com/tokio-rs/mio/blob/7ed74bf478230a0cfa7543901f6be6df8bb3602e/.github/workflows/ci.yml#L115-L128, https://github.com/tokio-rs/mio/blob/7ed74bf478230a0cfa7543901f6be6df8bb3602e/Makefile#L20-L24. |
@Thomasdezeeuw absolutely, we have that, but it only runs a very basic set of tests and unfortunately some findings slipped through that, and were only later caught in the full test run which also is done with the sanitized debug binary (built with a nightly compiler). So a big part of our testing is done on a binary built with a nightly compiler which is not really that great. For any C or C++ program I like to enable the sanitizer all the time (especially during development) and only leave out the instrumentation for the release build. Having this feature unstable makes this a bit awkward. This just seems strange, because it is such an important feature, that (for me) works flawlessly. |
Add support for LLVM SafeStack Adds support for LLVM [SafeStack] which provides backward edge control flow protection by separating the stack into two parts: data which is only accessed in provable safe ways is allocated on the normal stack (the "safe stack") and all other data is placed in a separate allocation (the "unsafe stack"). SafeStack support is enabled by passing `-Zsanitizer=safestack`. [SafeStack]: https://clang.llvm.org/docs/SafeStack.html cc `@rcvalle` rust-lang#39699
Do we control the output or does the plugin?
If we are able to control it, some demangling would be nice |
You need the But in general it would be awesome if Rust could do that internally somehow. For me it is sometimes a problem, that the container/machine running my program needs the |
I do have llvm-symbolizer in path but I'm wondering if I need to manually add it to the ASAN args. I'm trying to get the sanitizers running on the rust library as some dogfooding for this feature (plus the sanity check of course), if anyone knows how to improve the result output then feel free to chime in at rust-lang/miri-test-libstd#21 🙂 edit: it's not in path on CI but it is in path for me on local and I'm getting the same results. Weird... |
llvm-symbolizer supports rustc -Csymbol-mangling-version=v0. |
v0 is the default anyway right? The output without symbolizer isn't useful, https://github.com/rust-lang/miri-test-libstd/actions/runs/6429779032/job/17459492252?pr=21#step:4:70, with symbolizer it is https://github.com/rust-lang/miri-test-libstd/actions/runs/6434877064/job/17474985110?pr=21#step:4:69. Which is significantly more useful, but doesn't seem to handle everything
|
The legacy format is still the default one. The legacy format also happens to be embedded inside Itanium, so it can be partially demangled as you can see above, but generics aren't intelligible without dedicated support. |
Can I ask a potentially dumb question? Why is there no UndefinedSanitizer here? C and C++ both have ubsan but I don't see it here. |
…r=rcvalle Allow disabling ASan instrumentation for globals AddressSanitizer adds instrumentation to global variables unless the [`no_sanitize_address`](https://llvm.org/docs/LangRef.html#global-attributes) attribute is set on them. This commit extends the existing `#[no_sanitize(address)]` attribute to set this; previously it only had the desired effect on functions. (cc rust-lang#39699)
…r=rcvalle Allow disabling ASan instrumentation for globals AddressSanitizer adds instrumentation to global variables unless the [`no_sanitize_address`](https://llvm.org/docs/LangRef.html#global-attributes) attribute is set on them. This commit extends the existing `#[no_sanitize(address)]` attribute to set this; previously it only had the desired effect on functions. (cc rust-lang#39699)
…r=rcvalle Allow disabling ASan instrumentation for globals AddressSanitizer adds instrumentation to global variables unless the [`no_sanitize_address`](https://llvm.org/docs/LangRef.html#global-attributes) attribute is set on them. This commit extends the existing `#[no_sanitize(address)]` attribute to set this; previously it only had the desired effect on functions. (cc rust-lang#39699)
Rollup merge of rust-lang#127483 - BertalanD:no_sanitize-global-var, r=rcvalle Allow disabling ASan instrumentation for globals AddressSanitizer adds instrumentation to global variables unless the [`no_sanitize_address`](https://llvm.org/docs/LangRef.html#global-attributes) attribute is set on them. This commit extends the existing `#[no_sanitize(address)]` attribute to set this; previously it only had the desired effect on functions. (cc rust-lang#39699)
Currently we have:
A rustc flag,
-Z sanitizer
, to sanitize rlibs (it adds an extra LLVM pass/attribute) and executables (it links to the sanitizer runtime). Added in LeakSanitizer, ThreadSanitizer, AddressSanitizer and MemorySanitizer support #38699.An attribute
#[no_sanitize]
to disable sanitization on specific functions. Also lints if those functions are marked as requesting inlining. Added in Selectively disable sanitizer instrumentation #68164.#[no_sanitize]
suppresses#[inline]
hints. A lint is issued if combined with#[inline(always)]
.A few violations (false positives?) in the test runner
rustc --test
) ThreadSanitizer detects a data race in the test runner (rustc --test
) #39608rustc --test
) MemorySanitizer detects an use of unitialized value in the test runner (rustc --test
) #39610Known issues
Unresolved questions:
#[no_sanitize]
or perhaps something like#[sanitize(never)]
or some other variation? In particular, might we at some point want "positive options" like#[sanitize(miri(aggressive))]
? There is much back and forth in Selectively disable sanitizer instrumentation #68164.The text was updated successfully, but these errors were encountered: