Tracking issue for sanitizer support #39699
Comments
japaric
added
B-unstable
|
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. |
alexcrichton
added
T-dev-tools
|
#42711 PR for dylib asan support. |
Mark-Simulacrum
added
the
C-tracking-issue
|
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? |
jonas-schievink
added
the
A-sanitizers
|
|
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 |
|
I'm getting |
|
I have a problem. Why is there no specific number of lines displayed here? Excuse me, I've taken care of it. |
LLVM has built-in heuristics for adding stack canaries to functions. These
heuristics can be selected with LLVM function attributes. This patch adds a
rustc option `-Z stack-protector={none,basic,strong,all}` which controls the use
of these attributes. This gives rustc the same stack smash protection support as
clang offers through options `-fno-stack-protector`, `-fstack-protector`,
`-fstack-protector-strong`, and `-fstack-protector-all`. The protection this can
offer is demonstrated in test/ui/abi/stack-protector.rs. This fills a gap in the
current list of rustc exploit
mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html),
originally discussed in rust-lang#15179.
Stack smash protection adds runtime overhead and is therefore still off by
default, but now users have the option to trade performance for security as they
see fit. An example use case is adding Rust code in an existing C/C++ code base
compiled with stack smash protection. Without the ability to add stack smash
protection to the Rust code, the code base artifacts could be exploitable in
ways not possible if the code base remained pure C/C++.
Stack smash protection support is present in LLVM for almost all the current
tier 1/tier 2 targets: see
test/assembly/stack-protector/stack-protector-target-support.rs. The one
exception is nvptx64-nvidia-cuda. This patch follows clang's example, and adds a
warning message printed if stack smash protection is used with this target (see
test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3
targets has not been checked.
Since the heuristics are applied at the LLVM level, the heuristics are expected
to add stack smash protection to a fraction of functions comparable to C/C++.
Some experiments demonstrating how Rust code is affected by the different
heuristics can be found in
test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is
potential for better heuristics using Rust-specific safety information. For
example it might be reasonable to skip stack smash protection in functions which
transitively only use safe Rust code, or which uses only a subset of functions
the user declares safe (such as anything under `std.*`). Such alternative
heuristics could be added at a later point.
LLVM also offers a "safestack" sanitizer as an alternative way to guard against
stack smashing (see rust-lang#26612). This could possibly also be included as a
stack-protection heuristic. An alternative is to add it as a sanitizer (rust-lang#39699).
This is what clang does: safestack is exposed with option
`-fsanitize=safe-stack`.
The options are only supported by the LLVM backend, but as with other codegen
options it is visible in the main codegen option help menu. The heuristic names
"basic", "strong", and "all" are hopefully sufficiently generic to be usable in
other backends as well.
Reviewed-by: Nikita Popov <nikic@php.net>
Extra commits during review:
- [address-review] make the stack-protector option unstable
- [address-review] reduce detail level of stack-protector option help text
- [address-review] correct grammar in comment
- [address-review] use compiler flag to avoid merging functions in test
- [address-review] specify min LLVM version in fortanix stack-protector test
Only for Fortanix test, since this target specifically requests the
`--x86-experimental-lvi-inline-asm-hardening` flag.
- [address-review] specify required LLVM components in stack-protector tests
- move stack protector option enum closer to other similar option enums
- rustc_interface/tests: sort debug option list in tracking hash test
- add an explicit `none` stack-protector option
Revert "set LLVM requirements for all stack protector support test revisions"
This reverts commit a49b74f92a4e7d701d6f6cf63d207a8aff2e0f68.
add codegen option for using LLVM stack smash protection
LLVM has built-in heuristics for adding stack canaries to functions. These
heuristics can be selected with LLVM function attributes. This PR adds a codegen
option `-C stack-protector={basic,strong,all}` which controls the use of these
attributes. This gives rustc the same stack smash protection support as clang
offers through options `-fstack-protector`, `-fstack-protector-strong`, and
`-fstack-protector-all`. The protection this can offer is demonstrated in
test/ui/abi/stack-protector.rs. This fills a gap in the current list of rustc
exploit mitigations (https://doc.rust-lang.org/rustc/exploit-mitigations.html),
originally discussed in rust-lang#15179.
Stack smash protection adds runtime overhead and is therefore still off by
default, but now users have the option to trade performance for security as they
see fit. An example use case is adding Rust code in an existing C/C++ code base
compiled with stack smash protection. Without the ability to add stack smash
protection to the Rust code, the code base artifacts could be exploitable in
ways not possible if the code base remained pure C/C++.
Stack smash protection support is present in LLVM for almost all the current
tier 1/tier 2 targets: see
test/assembly/stack-protector/stack-protector-target-support.rs. The one
exception is nvptx64-nvidia-cuda. This PR follows clang's example, and adds a
warning message printed if stack smash protection is used with this target (see
test/ui/stack-protector/warn-stack-protector-unsupported.rs). Support for tier 3
targets has not been checked.
Since the heuristics are applied at the LLVM level, the heuristics are expected
to add stack smash protection to a fraction of functions comparable to C/C++.
Some experiments demonstrating how Rust code is affected by the different
heuristics can be found in
test/assembly/stack-protector/stack-protector-heuristics-effect.rs. There is
potential for better heuristics using Rust-specific safety information. For
example it might be reasonable to skip stack smash protection in functions which
transitively only use safe Rust code, or which uses only a subset of functions
the user declares safe (such as anything under `std.*`). Such alternative
heuristics could be added at a later point.
LLVM also offers a "safestack" sanitizer as an alternative way to guard against
stack smashing (see rust-lang#26612). This could possibly also be included as a
stack-protection heuristic. An alternative is to add it as a sanitizer (rust-lang#39699).
This is what clang does: safestack is exposed with option
`-fsanitize=safe-stack`.
The options are only supported by the LLVM backend, but as with other codegen
options it is visible in the main codegen option help menu. The heuristic names
"basic", "strong", and "all" are hopefully sufficiently generic to be usable in
other backends as well.
|
Is it possible to get a quick overview of the status of this? The ASAN on Linux seems to work really well and is an invaluable tool in a mixed Rust and C application. Is it possible to stabilize this in steps? After the incredible recent push of @joshtriplett to stabilize commonly used features like |
|
visiting for T-compiler backlog bonanza. @rustbot label: +S-tracking-needs-summary (We cannot tell what the current status of this thing is. Its clear from comments like the one immediately above that there are people interested in this and are using it.) |
rustbot
added
the
S-tracking-needs-summary
|
Wanted to voice my support for this for usage in fazi and also suggest that this should expand to whole packages. e.g. I would not like to instrument any code in Fazi, but any callers of Fazi should be instrumented. Additionally, I think |
|
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. |
and others
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: