Skip to content
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

Implement address sanitizer (ASAN) support #670

Closed
steveklabnik opened this issue Jan 21, 2015 · 5 comments
Closed

Implement address sanitizer (ASAN) support #670

steveklabnik opened this issue Jan 21, 2015 · 5 comments
Labels
T-dev-tools Relevant to the development tools team, which will review and decide on the RFC.

Comments

@steveklabnik
Copy link
Member

Issue by bstrie
Wednesday Dec 03, 2014 at 19:58 GMT

For earlier discussion, see rust-lang/rust#19504

This issue was labelled with: A-an-interesting-project, A-llvm, E-hard in the Rust repository


Backstory: being Valgrind-clean is a blocker for 1.0 (#13217). But Valgrind gives us tons of false positives (#5856) because of a specific tactic used by LLVM to generate optimized code (http://llvm.org/bugs/show_bug.cgi?id=12319). Neither LLVM nor Valgrind are incorrect here, so this is unlikely to ever be resolved (rust-lang/rust#5856 (comment)). And the overall volume of false positives is so great that we often succumb to just turning off Valgrind entirely to get any work done (rust-lang/rust#13217 (comment)).

There is an alternative: ASAN, which is integrated into LLVM and designed to produce no false positives in addition to being relatively low on runtime overhead (https://address-sanitizer.googlecode.com/files/address_sanity_checker.pdf). It is sponsored by Google and used in Chromium to great effect. But adding support is nontrivial:

This really needs to be refiled as "implement address sanitizer support" which is a huge project. It's not useful without frontend support, and IMO it's too much complexity to add to librustc in the current state it's in. Sanitizers would need to be added for all the unsafe intrinsics along with unsafe pointer dereferencing. It's not going to map well to the sanitizers used by Clang, since Rust does everything in the libraries with the basic compiler intrinsics. It doesn't have a language feature for unsafe indexing of arrays, etc.

rust-lang/rust#749 (comment)

Not only would ASAN support be a tremendous task, it would also ideally never generate any hits for Rust code. However, unsafe code exists, and developers can (and will (and have (we just don't know it yet))) get it wrong. More lines of defense are always valuable.

If you're looking for a very challenging and long-term but (IMO) very important Rust-related project to test your skills, this is the project for you.

@gnzlbg
Copy link
Contributor

gnzlbg commented Feb 3, 2015

Memory Sanitizer and Thread Sanitizer would also be very useful.

@kmcallister
Copy link
Contributor

This is a high priority for me. Among other reasons, it makes afl much more powerful.

I had a quick poke around the llvm/clang sources. It looks like almost all of ASan is in compiler-rt and llvm, which we can reuse. I'm sure we will run into some of the complications discussed on rust-lang/rust#749. I also would not be surprised if some of what strcat said turns out to be FUD.

Anyway I would love to see someone jump in and make progress on ASan support, even if it's not glitch-free. I can mentor with the rustc side (not so much the LLVM side).

unsafe code exists, and developers can (and will (and have (we just don't know it yet))) get it wrong

lol, I can give you plenty of examples, from my code and others. :)

@alexcrichton alexcrichton added the T-dev-tools Relevant to the development tools team, which will review and decide on the RFC. label May 18, 2015
@vks
Copy link

vks commented Jan 13, 2017

Also see rust-lang/rust#31605.

@burdges
Copy link

burdges commented Jan 25, 2017

As an aside, Nick Matheson's Tor bug retrospective makes interesting reading and suggests that this matters.

@Manishearth
Copy link
Member

This merged with rust-lang/rust#38699

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-dev-tools Relevant to the development tools team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

7 participants