Miri chould warn on creating reference to improper uninit

[CAD97]

Creating a reference to uninit data is most likely in error if the pointee type does not support uninit, even though this is most likely valid in the opsem. Warning in this case would be helpful in catching bugs earlier.

This is most helpful for vs , since this pointer composition operation is rarer than the normal referennce-of operation.

Specifically, I suggest checking primarily core::slice::from_raw_parts[_mut] (suggest to use core::ptr::slice_from_raw_part[_mut]), as this is effectively the stable primitive for going from raw pointer to slice reference. Checking on reference-of to places behind an unsafe pointer indirection (not that were behind a safe reference already) is also useful (suggest to use &raw), but probably needs a completely different mechanism to do the checking.

I do not envision this doing full type validation. Instead, it would just check for all-uninit and whether all-uninit is valid for the pointee type. This is a lint to detect accidental exposure to uninit earlier.

Original description

[example]

let layout = Layout::array::<u8>(10).unwrap();
let ptr = alloc(layout);
slice::from_raw_parts_mut(ptr, 10);
dealloc(ptr, layout);

This would have prevented an actual issue I had where I accidentally used slice::from_raw_parts instead of ptr::slice_from_raw_parts from a version-aware import.

More generally, this is the "create reference to uninitialized memory" catch, but since these two methods have now-stable sound alternatives, it'd be nice for miri to catch incorrect usage and point at the correct raw pointer version.

[CAD97]

And, as it turns out, would've caught an even more insidious bug of the same ilk, where my probe for slice_from_raw_parts stability was bugged.

[RalfJung]

This is currently deliberate. Quoting from the README:

In particular, Miri does currently not check that integers are initialized or that references point to valid data.

The reasoning is that I think this will complain about tons of stuff and make Miri basically unusable. Additionally, checking recursively below references will be extremely slow. The discussion in the UCG was mostly moving towards "we probably eventually want to accept that code", so I figured I'd make Miri less aggressive here.

I suppose we could offer a flag for more aggressive checking, for those that want it. However, checking transitively below references is expensive, I don't think we can reasonably do it -- and fixing this issue would require traversing below a reference.

[oli-obk]

We could do it on the result of calls to const fn that take raw pointers and yield references. That should be rare enough and should at some point cover all such constructor functions

[CAD97]

Yeah, this is intended to just be for some small "easier" subset. That could be just slice::from_raw_parts with a special message to use ptr::slice_from_raw_parts instead, or it could be more general like const fn.

[RalfJung]

That feels like a rather unprincipled hack to me... ad-hoc diagnostics for special cases are fine and useful, but ad-hoc changes to the basic semantics are somewhat disconcerting, IMO.

[cmazakas]

Being able to form a mutable slice to an unitialized region of memory isn't a bug and is instead a feature.

Consider networking buffers which must first allocate memory which then immediately gets read into. Forcing initialization of these bytes makes erroneous reads "safe" but it does slightly hinder perf.

[bjorn3]

You should use &[MaybeUninit<u8>] instead. &[u8] requires all u8 elements to be initialized.

[CAD97]

Technically the validity (including initializedness) of anything behind a reference is an open question. Even if constructing a reference to uninitialized data is valid, it's still likely that performing any kind of typed copy of that reference (such as passing it to a function) asserts that the value behind the reference is valid. On top of that, even for data that is trivially dropped by forgetting, it's likely that a reference write still asserts that the value previously there is valid.

TL;DR using references to uninitialized data in a regular type is at the very best unclear if it's sound, and likely to be determined unsound as we nail down the memory and borrowing model for Rust.

Use raw pointers and/or MaybeUninit if you need to write into maybe uninitialized memory. Read::read is definitely not allowed to write into uninitialized memory with the currently understood and defined subset of Rust's memory model, even with a known trait implementation.

[RalfJung]

Being able to form a mutable slice to an unitialized region of memory isn't a bug and is instead a feature.

It's a feature only if you tell the compiler that you are doing it. Just be explicit, that's all. You can be explicit by using MaybeUninit or raw pointers.

[cmazakas]

Well, I'm happy to stand corrected!

[saethlin]

I think Miri flagged an example of this:
https://github.com/rust-lang/rust/blob/e6b883c74f49f32cb5d1cbad3457f2b8805a4a38/library/alloc/src/str.rs#L180-L181

        let pos = result.len();
        let target = result.get_unchecked_mut(pos..reserved_len);

(reported here: rust-lang/rust#91574)

This is only flagged with -Zmiri-tag-raw-pointers. Is this an unintentional increase in accuracy, or am I misunderstanding the above discussion?