Android/Linux: Support msan; unpoison output of getrandom syscall. #463
Conversation
None of the tests are testing `getrandom_uninit()` directly, but instead it is marked as covered because `getrandom()` forwards to it. However, this means we're never testing an uninitialized input to `getrandom_uninit()`. Fix that.
briansmith
force-pushed
the
b/msan-1
branch
3 times, most recently
from
e791121 to
f4a95fe
Compare
|
If we moved away from using |
I will comment in that issue. In short, keeping the |
|
Note that this incorporates the changes in #462. |
|
Also note that the tests added in #462 fail when with Memory Sanitizer enabled before these changes, but pass after these changes, using the command line added to the crate-level documentation. |
|
Aren't we supposed to check for sanitizers like |
tests/common/mod.rs
Outdated
| #[allow(unused_variables)] | ||
| fn check_initialized(buf: &[MaybeUninit<u8>]) { | ||
| #[cfg(feature = "unstable-sanitize")] | ||
| { | ||
| // XXX: `#![feature(cfg_sanitize)]` doesn't enable the feature gate correctly. | ||
| // #[cfg(sanitize = "memory")] | ||
| { | ||
| use core::ffi::c_void; | ||
| extern "C" { | ||
| // void __msan_check_mem_is_initialized(const volatile void *x, size_t size); | ||
| fn __msan_check_mem_is_initialized(x: *const c_void, size: usize); | ||
| } | ||
| unsafe { | ||
| __msan_check_mem_is_initialized(buf.as_ptr().cast::<c_void>(), buf.len()); | ||
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Instead of this complexity, can we just do something in the huge tests which reads the huge buffer. Then MSAN will fail if we've messed up, but we don't need to have any cfg-specific code in our tests.
There was a problem hiding this comment.
Yes, we could maybe do the same thing we do for the large tests? I didn't want to try understanding what the large test is doing, so this was easier :) Also I was curious about whether __msan_check_mem_is_initialized would work.
Yes, but I couldn't get it to work. You can see that the |
| @@ -52,6 +52,8 @@ rustc-dep-of-std = [ | |||
| "libc/rustc-dep-of-std", | |||
| "wasi/rustc-dep-of-std", | |||
| ] | |||
| # Enable support for sanitizers; Requires Rust feature `cfg_sanitize`. | |||
| unstable-sanitize = [] | |||
There was a problem hiding this comment.
Isn't it better to use a configuration flag for this instead of this crate feature?
There was a problem hiding this comment.
Maybe. The good thing about using a feature flag is that other crates can then trigger it automatically with their own feature flag depending on it. That's what I've been planning to do in ring, for example.
briansmith
force-pushed
the
b/msan-1
branch
4 times, most recently
from
bd7ea32 to
de26fa5
Compare
See the added comment for details.
|
PR #467 adds a commit that disables the poison call to show that the new msan CI jobs work. See the job fail at https://github.com/rust-random/getrandom/actions/runs/9423708743/job/25962648547, with output: |
There isn't a bug; I just was missing the feature gate in the integration tests and misread the output. All fixed now. |
This stops using weird include hacks to reuse code. Instead, we move the code to a nomral `tests.rs` file and use helper functions to avoid code duplication. This also simplifies our testing of the custom RNGs. Before, we had to disable the "normal" tests to test the custom RNG. Now, the custom RNG is "good enough" to simply pass the tests. I also added direct testing for the `uninit` methods and verified that ``` RUSTFLAGS="-Zsanitizer=memory" cargo +nightly test -Zbuild-std --target=x86_64-unknown-linux-gnu ``` fails (but passes when #463 is added), so we are actually testing the right stuff here. So this can replace #462 Signed-off-by: Joe Richey <[email protected]>
|
Closing in favor of #521. It uses less granular unpoisoning in |
See the added comment for details.