Potential unsoundness in `unsafe_casts::any_as_u8_slice` due to struct padding

[lewismosciski]

Hello,

First, thank you for your work on the borrowck_sacrifices crate. It's a very interesting exploration of Rust's borrow capabilities.

Our team is currently developing a static analysis tool for Rust, and during our testing, we believe we have identified a potential soundness issue in the unsafe_casts::any_as_u8_slice function.

borrowck_sacrifices/src/unsafe_casts.rs

Lines 25 to 29 in 3d22abb

	pub fn any_as_u8_slice<'a,T: Sized>(p: &'a T) -> &'a [u8] {
	unsafe{
	::core::slice::from_raw_parts((p as *const T) as *const u8, ::core::mem::size_of::<T>())
	}
	}

It appears that any_as_u8_slice can create a byte slice (&[u8]) that references uninitialized memory when used with types that contain padding bytes. According to the Rustonomicon and the official documentation for slice::from_raw_parts, creating a reference to uninitialized memory is Undefined Behavior.

POC:

use borrowck_sacrifices::unsafe_casts::any_as_u8_slice;

struct MyStruct {
    _a: u8,  
    _b: u32,
}

fn main() {
    let h = MyStruct { _a: 1, _b: 2 };
    let bytes: &[u8] = any_as_u8_slice(&h);
    println!("{:?}", bytes);
}

Verified with miri:

ccuu@ccuu-H3CDesk-D500t:~/Desktop/rust/test1$ cargo +nightly miri run
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.02s
     Running `/home/ccuu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri runner target/miri/x86_64-unknown-linux-gnu/debug/test1`
error: Undefined Behavior: reading memory at alloc130[0x5..0x6], but memory is uninitialized at [0x5..0x6], and this operation requires initialized memory
   --> /home/ccuu/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/fmt/num.rs:599:5
    |
599 |     impl_Display!(i8, u8, i16, u16, i32, u32, i64, u64, isize, usize; as u64 into display_u64);
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Undefined Behavior occurred here
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior

Perhaps the most direct fix is to change the function signature to pub unsafe fn any_as_u8_slice .... This would make the API contract honest about its potential dangers.

[alexpyattaev]

Thank you for looking into this!

Yes, this is indeed a peculiar problem in rust. All this function does is give you a view into the underlying memory representation, whatever it happens to be.

You can get uninitialized data by feeding a MaybeUninit into this function. However, this might be acceptable since the optimizer does not make assumptions about the contents of a byte slice. Making fn unsafe would not make any difference in practice if you are actually reading from offsets that are not initialized.

Can you demonstrate how this function would result in a correct program that would be exhibiting actual runtime issues?

[lewismosciski]

Hi @alexpyattaev ,

Thank you for the quick reply and for engaging with this issue. I appreciate you taking the time to discuss it.I believe the core of our disagreement comes down to how Rust defines soundness and Undefined Behavior as a strict contract between the programmer and the compiler.

Let me lay out the argument based on the official documentation, which I hope will clarify my position.

1. The Safety Contract of slice::from_raw_parts

Your function relies on from_raw_parts, which has a very strict safety contract. Any code calling it must guarantee its conditions are met. The documentation is explicit:

Behavior is undefined if any of the following conditions are violated:
...
data must point to len consecutive properly initialized values of type T.
...

2. What Undefined Behavior Means

You asked for a demonstration of a runtime issue, and the Miri report is that demonstration. UB doesn't just mean "a crash." It means the program has violated the fundamental rules of the language, and the contract with the compiler is now void.The documentation is explicit:

Rust code is incorrect if it exhibits any of the behaviors in the following list... unsafe only means that avoiding undefined behavior is on the programmer; it does not change anything about the fact that Rust programs must never cause undefined behavior.

3. A safe Function Must Be Sound

This leads to the final point: a safe function makes a promise that it's impossible for a safe caller to trigger UB. If that promise can be broken, the function is unsound. My poc showed that by using safe code, I could trigger UB through your function's public API.

From the official Rust documentation:

Accordingly, we say that a library (or an individual function) is sound if it is impossible for safe code to cause Undefined Behavior using its public API. Conversely, the library/function is unsound if safe code can cause Undefined Behavior.

I hope this logical progression makes my reasoning clear. Thank you again for your work and for this important discussion.

references:
https://doc.rust-lang.org/reference/behavior-considered-undefined.html
https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library
https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html

[alexpyattaev]

Fixed in v0.2. You can take a look at https://github.com/anza-xyz/wincode/ and https://github.com/alexpyattaev/spatialtree also if you have the bandwidth.

[evilpie]

@alexpyattaev could you push the code for v0.2?

[alexpyattaev]

@alexpyattaev could you push the code for v0.2?

Done