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

Sport for fuzzing rust code #10

Open
Eh2406 opened this issue Dec 28, 2018 · 10 comments
Open

Sport for fuzzing rust code #10

Eh2406 opened this issue Dec 28, 2018 · 10 comments

Comments

@Eh2406
Copy link

Eh2406 commented Dec 28, 2018

Many people in the rust community are excited to see this project! Both because it is in Rust, and because we want to use it on Rust projects.

Is there any information on how to use it on Rust projects?

@spinpx
Copy link
Member

spinpx commented Dec 29, 2018

It's an interesting topic. As Shnatsel mentioned, the LLVM pass needs to support Rust's LLVM version. However, since Rust has many built-in libraries, modeling the built-in or external libraries used in rust for taint analysis will be the challenge.

@TheBlueMatt
Copy link
Contributor

At least to get things bootstrapped, ie without instrumenting rust's built-in libraries, it looks like building against system rustc/LLVM is pretty easy.

rustc appears to dynamically load LLVM/its LLVM codegen lib at runtime you can't just LD_PRELOAD angora-llvm-pass cause it wont be able to find LLVM hooks at load. This is just that llvm_mode/Makefile to include $(LLVM_CONFIG) --libs in the flags for angora-llvm-pass so that libLLVM gets loaded at start. I think this should be done upstream, so will open a PR in a sec.

Once you do that, you can just something that looks like LD_PRELOAD="/path/to/angora-llvm-pass.so /path/to/unfold-branch-pass.so" RUSTFLAGS="-C passes=unfold_branch_pass,angora_llvm_pass" cargo build.

For me this results in ICEs that look like this, I presume because I'm using LLVM 7, which is unsupported:
Incorrect number of arguments passed to called function!
%71 = call i32 @__angora_trace_cmp(i32 %69, i32 1374339812, i64 %70, i64 1), !dbg !232, !nosanitize !56

TheBlueMatt added a commit to TheBlueMatt/Angora that referenced this issue Dec 30, 2018
This allows us to LD_PRELOAD the pass libraries for rustc
which loads LLVM at runtime instead of via the linker.

See AngoraFuzzer#10 (comment) for more
@TheBlueMatt
Copy link
Contributor

Note that this is, of course, a little bit awkward, because building Angora requires a nightly rust (ie installed via rustup) and then you have to switch to system-installed rust (ie uninstall rustup/remove it from your PATH) to actually build things with the angora pass. It looks like Angora's nightly-requirement is just for nll (so we can switch to edition-2018 and stable there) and C-linked thread-locals (which I'm worried isn't well-defined anyway, would it be too much of a perf hit to take a function-call into a native-built C wrapper to read these?).

@TheBlueMatt
Copy link
Contributor

I'm also very confused (and know nothing about LLVM) because the #[thread_local] variables in shm_conds don't appear to be defined as thread-locals in angora-llvm-pass.so.cc (the second-to-last arg is 0, which in LLVM's GlobalValue.h appears to be:

enum ThreadLocalMode {
  NotThreadLocal = 0,

)

@spinpx
Copy link
Member

spinpx commented Jan 2, 2019

Hi, @TheBlueMatt . Thanks for your contribution. I merged your pull request on rust-stable branch.
I haven't tried Angora in LLVM 7. I will put the support for LLVM 7 in my plan.

For the thread local issues, I defined __angora_prev_loc, __angora_context in angora-llvm-pass.so.cc as:

  AngoraPrevLoc =
      new GlobalVariable(M, Int32Ty, false, GlobalValue::CommonLinkage,
                         ConstantInt::get(Int32Ty, 0), "__angora_prev_loc", 0,
                         GlobalVariable::GeneralDynamicTLSModel, 0, false);
  AngoraContext =
      new GlobalVariable(M, Int32Ty, false, GlobalValue::CommonLinkage,
                         ConstantInt::get(Int32Ty, 0), "__angora_context", 0,
                         GlobalVariable::GeneralDynamicTLSModel, 0, false);

And the LLVM API is

GlobalVariable (Module &M, Type *Ty, bool isConstant, LinkageTypes Linkage, 
Constant *Initializer, const Twine &Name="", GlobalVariable *InsertBefore=nullptr, 
ThreadLocalMode=NotThreadLocal, unsigned AddressSpace=0, 
bool isExternallyInitialized=false)

"The the second-to-last arg is 0" is for "AddreessSpace".
And I implemented the "native-built C wrapper" approach for thread local in the rust-statble branch.

@TheBlueMatt
Copy link
Contributor

TheBlueMatt commented Jan 2, 2019 via email

@spinpx
Copy link
Member

spinpx commented Jan 10, 2019

Thanks @bpfoley, we have an llvm6 branch now.
https://github.com/AngoraFuzzer/Angora/tree/llvm6
#24

I created llvm7 branch here:
https://github.com/AngoraFuzzer/Angora/tree/llvm7

#24 (comment) mentioned the compiling issues that I still have not solved.

@dragostis
Copy link

@spinpx, what is the state of this? Is there any way I can help move this forward?

@TheBlueMatt
Copy link
Contributor

@dragostis the next steps are probably to retrace the steps I took, above, using the llvm6/7 branch and see how far you can get. Note that you'll have to use system-LLVM (and a rustc built against that, eg use debian packages, not rustup, as afaict rustup doesn't ship the necessary bits of LLVM to build against).

@spinpx
Copy link
Member

spinpx commented Mar 28, 2019

We have implemented the new feature for supporting libdft64 here. https://github.com/AngoraFuzzer/Angora/blob/master/docs/pin_mode.md

Since it uses Intel Pin to do track analysis, we needn't compiling whole program now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants