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

Reference to uninitialized memory is not caught #2518

Closed
nandesu-utils opened this issue Aug 29, 2022 · 6 comments
Closed

Reference to uninitialized memory is not caught #2518

nandesu-utils opened this issue Aug 29, 2022 · 6 comments
Labels
C-support Category: Not necessarily a bug, but someone asking for support

Comments

@nandesu-utils
Copy link

An intermediary reference to uninitialized memory is not caught up. It is produced when taking that reference and then converting it to a pointer.

Rust playground permalink: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=811c791ba18d604f1553f1b2dd27108e

@nandesu-utils nandesu-utils changed the title Reference to uninitialized memory is not caught up Reference to uninitialized memory is not caught Aug 29, 2022
@bjorn3
Copy link
Member

bjorn3 commented Aug 29, 2022

When checking validity for references, the referenced memory is not checked for validity. This is by design I believe, but I can't quite explain why.

@nandesu-utils
Copy link
Author

nandesu-utils commented Aug 29, 2022

When checking validity for references, the referenced memory is not checked for validity. This is by design I believe, but I can't quite explain why.

Is it miri's design or Rust's one?

As it states here:

Producing an invalid value, even in private fields and locals. "Producing" a value happens any time a value is assigned to or read from a place, passed to a function/primitive operation or returned from a function/primitive operation. The following values are invalid (at their respective type):
...

  • A reference or Box that is dangling, unaligned, or points to an invalid value.

And also:

Uninitialized memory is also implicitly invalid for any type that has a restricted set of valid values.

As I understand creating a reference means producing it, and it is invalid because it is a reference that points to an invalid value which is uninitialized memory.

@5225225
Copy link
Contributor

5225225 commented Aug 30, 2022

We're not sure if this is UB or not (see: rust-lang/unsafe-code-guidelines#77).

But it probably won't be UB because it's difficult to check this (Every time you move a &[u8; 1_000_000], you have to check the whole of the array there Just In Case any of it has been invalidated)

Not to mention recursive types. These aren't impossible problems, but it would make the job of miri harder.

@saethlin
Copy link
Member

I do not think the performance arguments are compelling. I might be convinced, if someone would implement validity-behind-references, then give me time to try to make it faster.

But in any case, I think the much bigger concern is how surprising this would be for unsafe programmers, and how much existing code it would make invalid. Basically: rust-lang/unsafe-code-guidelines#346

@RalfJung
Copy link
Member

RalfJung commented Aug 31, 2022

This is indeed a deliberate difference between Miri and the Reference, and documented prominently in the README:

There are still plenty of open questions around the basic invariants for some types and when these invariants even have to hold. Miri tries to avoid false positives here, so if your program runs fine in Miri right now that is by no means a guarantee that it is UB-free when these questions get answered.

In particular, Miri does currently not check that references point to valid data.

A final decision for Rust semantics has not been made, so the reference is conservative and says this is forbidden. Miri does not guarantee to detect all UB and hence, for now, does not do these checks. I also hope we will officially allow such references to invalid data in the future; most people seem to be in favor of that. If someone wanted to implement them we could add an opt-in flag for these checks.

However, notice that references to uninhabited types are considered UB even by Miri, as this example shows.

@RalfJung RalfJung added the C-support Category: Not necessarily a bug, but someone asking for support label Aug 31, 2022
@RalfJung
Copy link
Member

RalfJung commented Oct 6, 2022

I am going to close this, since Miri behaves as intended and as documented. Feel free to ask any further questions that you have, though!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-support Category: Not necessarily a bug, but someone asking for support
Projects
None yet
Development

No branches or pull requests

5 participants