I would love to test this out on my project, but it looks like that there's not pre-built docker image.

You can host one on DockerHub or GitHub Container Registry. It would be really easier to try this out this way! 👍

This is a really cool project! We're trying to use Rudra with the nightly-2021-08-20 toolchain but there's a small issue — if a user pulls the ghcr.io/sslab-gatech/rudra:2021-08-20 image as specified in the readme and tags it with rudra:latest, running the docker-cargo-rudra script will give an error that the installed Rust toolchain does not match the RUSTUP_TOOLCHAIN env var. I think this PR should resolve that issue so that a user can set RUDRA_RUSTUP_TOOLCHAIN to override the variable passed to Docker.

Summary

Adapt SendSyncChecker's detection criteria for PtrLike types & Concurrent Queue types.

• PtrLike : Require T: Send + Sync for impl Sync
• Concurrent Queue : Allow T: Send to be enough for impl Sync

test cases relevant to this PR

• Detected by analyzer
  • tests/send_sync/wild_channel.rs => Detected
  • tests/send_sync/wild_ptr_like.rs => Detected
• Allowed by analyzer
  • tests/send_sync/okay_channel.rs => Allowed

Update on Feb 3rd: I decided to remove the PtrLike type handling in this PR, and maybe try again in a separate pr

For some reason Rudra isn't compiling when I use "derive(Default)" When I implement the Default explicitly I get no such issue. cargo test compiles & runs just fine either way.

Change to allow Rudra to compile - https://github.com/matanmarkind/active_standby/commit/5108cc54aeab191dde397384e6ead1acd98b4ff4

sudo RUDRA_RUNNER_HOME=~/rust/Rudra/rudra_runner ~/rust/Rudra/docker-helper/docker-cargo-rudra ~/rust/active_standby

2022-02-23 07:08:19.846614 |INFO | [rudra-progress] Running cargo rudra
2022-02-23 07:08:20.837016 |INFO | [rudra-progress] Running rudra for target lib:active_standby
error[E0277]: the trait bound `K: std::cmp::Ord` is not satisfied
   --> src/macros.rs:91:13
    |
91  |             inner: AsLockHandleAlias$(< $($Inner),* >)?,
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::cmp::Ord` is not implemented for `K`
    |
   ::: src/collections/btreemap.rs:66:5
    |
66  |     crate::generate_lockless_aslockhandle!(BTreeMap<K, V>);
    |     ------------------------------------------------------- in this macro invocation
    |
    = note: required because of the requirements on the impl of `std::default::Default` for `std::collections::BTreeMap<K, V>`
    = note: 1 redundant requirements hidden
    = note: required because of the requirements on the impl of `std::default::Default` for `lockless::aslockhandle::AsLockHandle<std::collections::BTreeMap<K, V>>`
note: required by `std::default::Default::default`
    = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider further restricting this bound
    |
89  |         #[derive(Default + std::cmp::Ord, Clone)]
    |                          +++++++++++++++

error[E0277]: the trait bound `T: std::cmp::Ord` is not satisfied
   --> src/macros.rs:91:13
    |
91  |             inner: AsLockHandleAlias$(< $($Inner),* >)?,
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::cmp::Ord` is not implemented for `T`
    |
   ::: src/collections/btreeset.rs:78:5
    |
78  |     crate::generate_lockless_aslockhandle!(BTreeSet<T>);
    |     ---------------------------------------------------- in this macro invocation
    |
    = note: required because of the requirements on the impl of `std::default::Default` for `std::collections::BTreeSet<T>`
    = note: 1 redundant requirements hidden
    = note: required because of the requirements on the impl of `std::default::Default` for `lockless::aslockhandle::AsLockHandle<std::collections::BTreeSet<T>>`
note: required by `std::default::Default::default`
    = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider further restricting this bound
    |
89  |         #[derive(Default + std::cmp::Ord, Clone)]
    |                          +++++++++++++++

error[E0277]: the trait bound `K: std::cmp::Ord` is not satisfied
   --> src/macros.rs:205:13
    |
205 |             inner: AsLockAlias$(< $($Inner),* >)?,
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::cmp::Ord` is not implemented for `K`
    |
   ::: src/collections/btreemap.rs:117:5
    |
117 |     crate::generate_shared_aslock!(BTreeMap<K, V>);
    |     ----------------------------------------------- in this macro invocation
    |
    = note: required because of the requirements on the impl of `std::default::Default` for `std::collections::BTreeMap<K, V>`
    = note: 1 redundant requirements hidden
    = note: required because of the requirements on the impl of `std::default::Default` for `shared::aslock::AsLock<std::collections::BTreeMap<K, V>>`
note: required by `std::default::Default::default`
    = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider further restricting this bound
    |
203 |         #[derive(Default + std::cmp::Ord)]
    |                          +++++++++++++++

error[E0277]: the trait bound `T: std::cmp::Ord` is not satisfied
   --> src/macros.rs:205:13
    |
205 |             inner: AsLockAlias$(< $($Inner),* >)?,
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::cmp::Ord` is not implemented for `T`
    |
   ::: src/collections/btreeset.rs:131:5
    |
131 |     crate::generate_shared_aslock!(BTreeSet<T>);
    |     -------------------------------------------- in this macro invocation
    |
    = note: required because of the requirements on the impl of `std::default::Default` for `std::collections::BTreeSet<T>`
    = note: 1 redundant requirements hidden
    = note: required because of the requirements on the impl of `std::default::Default` for `shared::aslock::AsLock<std::collections::BTreeSet<T>>`
note: required by `std::default::Default::default`
    = note: this error originates in the derive macro `Default` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider further restricting this bound
    |
203 |         #[derive(Default + std::cmp::Ord)]
    |                          +++++++++++++++

For more information about this error, try `rustc --explain E0277`.
error: could not compile `active_standby` due to 4 previous errors
2022-02-23 07:08:24.492177 |ERROR| [rudra-progress] Finished with non-zero exit code

When I use nightly-2021-08-20, it works OK. But nowadays, rust projects support many new features. If I use the same toolchain to compile them, errors like feature "edition2021" is required will appear. After I use new version of toolchain. Rudra failed in the compilation because miri was recently split into several crates, which makes rustc_mir unable to reach. The Rudra requires that the version of toolchains used to build Rudra and target projects must be same. What should I do?

Moreover, I'm very curious about how you analyze 43k packages mentioned in your paper. Is there a project or any scripts?

My Email: [email protected]

The rust version in the Dockerfile is from about one year ago, and a lot of new features have been implemented since then.

https://github.com/sslab-gatech/Rudra/blob/a2ea65cad7c3fc30c5f8d29a62411e0236af2a2c/Dockerfile#L8

I tried to change the rust version in the Dockerfile to the latest nightly:

-     RUST_VERSION=nightly-2020-08-26 \
+     RUST_VERSION=nightly-2021-08-20 \

which resulted in a compilation failure:

   Compiling rudra v0.1.0 (/tmp/rudra)
error[E0463]: can't find crate for `rustc_data_structures`
 --> src/lib.rs:7:1
  |
7 | extern crate rustc_data_structures;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ can't find crate

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: could not compile `rudra`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `rudra v0.1.0 (/tmp/rudra)`, intermediate artifacts can be found at `/tmp/rudra/target`

Caused by:
  build failed

I have added GitHub Actions support for Rudra so this should make is easier to users to just run in their workflow.

One thing to note is that I created a second Dockerfile which just pulls the latest version from GitHub Packages. This is because GitHub Actions will build the container versus pulling an image. Also it helped setting the Entrypoint for the image.

The second thing is that I have left the inputs but they are not used. I wanted to add support for the Action to error out if Rudra found anything but that can be added to inputs as a flag or enabled by default in Actions.

It would also be great to see the Action on the Actions Marketplace in the near future.

• Use a fixed DB dump from a forked cargo index.
• Try to use sccache to build dependencies if it is available.
• Improvement in environment variable handling.

This adds a new folder called stdlib-analysis that contains a convenience script to analyze the standard library.

This approach creates a small change in rudra to allow for this, in particular it adds:

• Adds a RUDRA_ALSO_ANALYZE environment variable. This variable causes rudra to also analyze a comma separated list of crates passed in. For example, if we're building crate foo with dependencies bar and baz. We can use RUDRA_ALSO_ANALYZE=bar,baz to analyze both the build dependencies.
• -Zrudra-act-as-compiler, a rudra flag that makes the analyzer compile instead of just stopping compilation. This is needed because we're trying to analyze dependent crates that are built by xargo. Thus since we have a chain of build dependencies like core -> alloc -> std, we can't just stop building after we've analyzed the first crate.

I also have an alternative approach that creates a bin/rudra-std.rs file but it either involves refactoring out a lot of the common code from bin/cargo-rudra.rs and bin/rudra.rs OR duplicating code. Please let me know if you would like to see those.

Error message:

error: internal compiler error: compiler/rustc_middle/src/ty/subst.rs:538:17: type parameter `U/#1` (U/1) out of range when substituting, substs=[U]

thread 'rustc' panicked at 'Box<dyn Any>', /rustc/6d64f7f695943541fe12bb960971403f440d7225/compiler/rustc_errors/src/lib.rs:1061:9
stack backtrace:
   0: std::panicking::begin_panic
   1: std::panic::panic_any
   2: rustc_errors::HandlerInner::span_bug
   3: rustc_errors::Handler::span_bug
   4: rustc_middle::ty::context::tls::with_opt
   5: rustc_middle::util::bug::opt_span_bug_fmt
   6: rustc_middle::util::bug::span_bug_fmt
   7: <rustc_middle::ty::subst::SubstFolder as rustc_middle::ty::fold::TypeFolder>::fold_ty
   8: rudra::analysis::unsafe_dataflow::inner::fn_called_on_copy
   9: rudra::analysis::unsafe_dataflow::inner::UnsafeDataflowBodyAnalyzer::analyze_body
  10: rudra::analysis::unsafe_dataflow::UnsafeDataflowChecker::analyze
  11: rudra::analyze
  12: <rudra::RudraCompilerCalls as rustc_driver::Callbacks>::after_analysis
  13: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  14: rustc_span::with_source_map
  15: scoped_tls::ScopedKey<T>::set

It will likely fail for other crates too.

tl;dr: is there a collection of standalone examples demonstrating the power of Rudra?

Hi,

I'm attempting to "play around" with Rudra and run some "toy" examples, but I'm not having much success.

If I run the following:

for i in tests/*/*.rs; do rudra --crate-type lib $i; done

Then I do get Rudra-based warnings on the following (I didn't show the SendSyncVariance issues):

• Error (UnsafeDataflow:/WriteFlow/VecSetLen): Potential unsafe dataflow issue in 'MyVec::<T>::push_all'
• Info (UnsafeDataflow:/Transmute): Potential unsafe dataflow issue in 'test_order_unsafe'
• Warning (UnsafeDataflow:/ReadFlow): Potential unsafe dataflow issue in 'test_order_unsafe_loop'
• Warning (UnsafeDataflow:/ReadFlow): Potential unsafe dataflow issue in 'test_order_unsafe'
• Warning (UnsafeDataflow:/ReadFlow/CopyFlow/WriteFlow): Potential unsafe dataflow issue in 'insertion_sort_unsafe'

So far so good, so I think that means that my Rudra build is working ... so I then I tried to create my own examples.

Example 1

Taken from: https://github.com/rust-lang/rust/issues/80894 / https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c0ea390522bda958c9d60ad47a42e296

#![forbid(unsafe_code)]

use std::io::Read;

struct MyRead {
    first: bool,
}

impl MyRead {
    pub fn new() -> Self {
        MyRead { first: false }
    }
}

impl Read for MyRead {
    fn read(&mut self, _buf: &mut [u8]) -> std::io::Result<usize> {
        if !self.first {
            self.first = true;
            // First iteration: return more than the buffer size
            Ok(64)
        } else {
            // Second iteration: indicate that we are done
            Ok(0)
        }
    }
}

struct VecWrapper {
    inner: Vec<u8>,
}

impl VecWrapper {
    pub fn new() -> Self {
        VecWrapper { inner: Vec::new() }
    }
}

impl Drop for VecWrapper {
    fn drop(&mut self) {
        // Observe uninitialized bytes
        println!("{:?}", &self.inner);
        // Overwrite heap contents
        for b in &mut self.inner {
            *b = 0x90;
        }
    }
}

fn main() {
    let mut vec = VecWrapper::new();
    let mut read = MyRead::new();
    read.read_to_end(&mut vec.inner).unwrap();
}

rudra --crate-type bin main.rs:

2023-01-03 10:32:13.123601 |INFO | [rudra-progress] Rudra started
2023-01-03 10:32:13.124523 |INFO | [rudra-progress] SendSyncVariance analysis started
2023-01-03 10:32:13.124571 |INFO | [rudra-progress] SendSyncVariance analysis finished
2023-01-03 10:32:13.124593 |INFO | [rudra-progress] UnsafeDataflow analysis started
2023-01-03 10:32:13.129166 |INFO | [rudra-progress] UnsafeDataflow analysis finished
2023-01-03 10:32:13.129196 |INFO | [rudra-progress] Rudra finished

That is, no warnings.

Example 2

Inspired from: https://github.com/andydude/rust-sha/issues/2 / https://github.com/sslab-gatech/Rudra-PoC/blob/master/poc/0148-sha.rs

fn to_bytes_len(len: usize) -> Vec<u8> {
    let mut bytes: Vec<u8> = Vec::with_capacity(len);
    unsafe {
        bytes.set_len(len);
    };
    bytes
}

fn main() {
    let x = to_bytes_len(10);
    println!("{}", x[0]);
}

rudra --crate-type bin main.rs:

2023-01-03 10:35:18.845653 |INFO | [rudra-progress] Rudra started
2023-01-03 10:35:18.846712 |INFO | [rudra-progress] SendSyncVariance analysis started
2023-01-03 10:35:18.846773 |INFO | [rudra-progress] SendSyncVariance analysis finished
2023-01-03 10:35:18.846786 |INFO | [rudra-progress] UnsafeDataflow analysis started
2023-01-03 10:35:18.847592 |INFO | [rudra-progress] UnsafeDataflow analysis finished
2023-01-03 10:35:18.847647 |INFO | [rudra-progress] Rudra finished

That is, no warnings.

Based on the description from https://github.com/andydude/rust-sha/issues/2 I was hoping this would exhibit:

This is unsound, because it allows safe Rust code to exhibit an undefined behavior (read from uninitialized memory).

Question

Should I be able to use Rudra like this? Are these false negatives in Rudra, or are the examples "bad" (i.e., they don't contain issues)?

Alternatively, do you have a collection of standalone examples that demonstrate the kind of problems that Rudra can find? I'd hoped that maybe the tests would show this, but as there are only ~~three~~five UnsafeDataflow issues in the test-suite, I was thinking that there might be more examples of the issues that Rudra can find!

Version info

rudra --version
rustc 1.56.0-nightly (6d64f7f69 2021-08-19)

rustc --version
rustc 1.56.0-nightly (6d64f7f69 2021-08-19)

rustup toolchain list
beta-aarch64-apple-darwin
nightly-2021-08-20-aarch64-apple-darwin (default)
nightly-2022-11-20-aarch64-apple-darwin
nightly-aarch64-apple-darwin

Thanks for your help and for building Rudra -- cheers,

Andrew

I am running the rudra container in CI on a library using bindgen to generate bindings from C code.

Currently when I run Rudra in the project directory, I see this output.

$ cargo rudra
2022-02-02 16:35:37.967764 |INFO | [rudra-progress] Running cargo rudra
2022-02-02 16:35:39.541463 |INFO | [rudra-progress] Running rudra for target lib:tf_bindings
2022-02-02 16:36:05.063560 |INFO | [rudra-progress] Rudra started
2022-02-02 16:36:05.063824 |INFO | [rudra-progress] SendSyncVariance analysis started
2022-02-02 16:36:05.063840 |INFO | [rudra-progress] SendSyncVariance analysis finished
2022-02-02 16:36:05.063843 |INFO | [rudra-progress] UnsafeDataflow analysis started
2022-02-02 16:36:05.072000 |INFO | [rudra-progress] UnsafeDataflow analysis finished
2022-02-02 16:36:05.072021 |INFO | [rudra-progress] Rudra finished
2022-02-02 16:36:05.445477 |WARN | [cargo_rudra] Target custom-build:build-script-build is not supported
2022-02-02 16:36:05.445506 |INFO | [rudra-progress] cargo rudra finished

Is there a workaround for Target custom-build:build-script-build is not supported or something different I need to be doing?

Thanks

It would be awesome if Rudra could support Static Analysis Results Interchange Format (SARIF) so that I can publish results from Rudra into GitHub Advanced Security's Code Scanning.

I would check out sarif-rs which is what tools like Clippy will be / are using. A GitHub Action would also be needed #20.

This then could be used for open source repositories that want to use Rudra to then just be able to add the Rudra Action, run the tool, and then upload the results to GitHub Code Scanning.

+cc @josepalafox

Currently, 2021 crates can't be analyzed because the feature is still unstable in the version used by rudra:

$ docker-cargo-rudra .
2021-11-14 06:39:02.906467 |INFO | [rudra-progress] Running cargo rudra
2021-11-14 06:39:03.166856 |ERROR| [rudra-progress] Could not obtain Cargo metadata
Error during execution of `cargo metadata`: error: failed to load manifest for workspace member `/tmp/rudra/...`

Caused by:
  feature `edition2021` is required

  The package requires the Cargo feature called `edition2021`, but that feature is not stabilized in this version of Cargo (1.56.0-nightly (e96bdb0c3 2021-08-17)).
  Consider adding `cargo-features = ["edition2021"]` to the top of Cargo.toml (above the [package] table) to tell Cargo you are opting in to use this unstable feature.
  See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#edition-2021 for more information about the status of this feature.

When I execute cargo rudra for other crates, there is an error:

dyld: Library not loaded: @rpath/librustc_driver-0fd0d43d50587954.dylib
Referenced from: /Users/vaynnecol/.cargo/bin/cargo-rudra
Reason: image not found
[1] 91286 abort cargo rudra

and this error does not apper when i running Rudra for itself.