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

add -Zmiri-strict-provenance #2045

Merged
merged 1 commit into from
Apr 1, 2022
Merged

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Apr 1, 2022

This implements strict provenance in Miri. The only change is that casting an integer to a pointer does not even attempt to produce a good provenance for the given address; instead, it always uses the invalid provenance. This stricter than even -Zmiri-tag-raw-pointers in that it also rejects the following example (which does not even involve Stacked Borrows):

fn main() {
    let x = 22;
    let ptr = &x as *const _ as *const u8;
    let roundtrip = ptr as usize as *const u8;
    let _ = unsafe { roundtrip.offset(1) };
}

The new flag also implies -Zmiri-tag-raw-pointers since the only reason one would not want to tag raw pointers is to support ptr-int-ptr roundtrips.

Note that the flag does not check against ptr-to-int transmutes; that still requires -Zmiri-check-number-validity. You can also check for strict provenance without Stacked Borrows by adding -Zmiri-disable-stacked-borrows.

The new "Miri hard mode" flags for maximal checking are -Zmiri-strict-provenance -Zmiri-check-number-validity. (Add -Zmiri-symbolic-alignment-check if you feel extra spicy today.)

@JakobDegen
Copy link
Contributor

And don't forget RUSTFLAGS="-Zrandomize-layout"!

@bgeron
Copy link

bgeron commented Apr 1, 2022

I'm trying to convince the community that strict_provenance doesn't mean we need to break backwards compatibility. The confusion between "new functionality" vs "break existing code" has been causing anger and confusion.

In that context, I propose to rename this flag to -Zmiri-strict-only-provenance — as permissive provenance is no more.

Ideally I would like specific functions to stdlib for strict-provenance conversions, so that we have interpret both sets of operations differently in Miri. But we can't do that in this MR. So a rename is preferable.

@RalfJung
Copy link
Member Author

RalfJung commented Apr 1, 2022

@bgeron I don't quite see what that extra "only" would accomplish. The entire thing is called "strict provenance experiment", and "following strict provenance" means to follow the rules of the experiment. The confusion is around whether rustc is been given license to assume that all code follows strict provenance (no, it is not). But following strict provenance makes it much easier (or sometimes is required to make it possible) to check your code with Miri or CHERI, and that is what this flag corresponds to.

What the flag does is enforce the rules of strict provenance. If anything we could name it -Zmiri-enforce-strict-provenance but that seems just unnecessarily verbose.

@RalfJung
Copy link
Member Author

RalfJung commented Apr 1, 2022

interpret both sets of operations differently in Miri

That would basically mean not having a strict provenance memory model, so it doesn't need a flag. It is currently the default.

Maybe one day we can swap the default, but that's a different question.

@bgeron
Copy link

bgeron commented Apr 1, 2022

Fair point.

@RalfJung
Copy link
Member Author

RalfJung commented Apr 1, 2022

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 1, 2022

📌 Commit 9af03bf has been approved by RalfJung

@bors
Copy link
Collaborator

bors commented Apr 1, 2022

⌛ Testing commit 9af03bf with merge 732461b...

@bors
Copy link
Collaborator

bors commented Apr 1, 2022

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 732461b to master...

@bors bors merged commit 732461b into rust-lang:master Apr 1, 2022
@RalfJung RalfJung deleted the strict-provenance branch April 1, 2022 23:47
bors bot added a commit to tock/libtock-rs that referenced this pull request Jun 14, 2022
410: Enable strict provenance in Miri. r=jrvanwhy a=jrvanwhy

This merges the two miri commands together, as strict provenance is strictly more restrictive than all other configurations.

See rust-lang/miri#2045 for some more background on `-Zmiri-strict-provenance`.

Closes #400 

Co-authored-by: Johnathan Van Why <jrvanwhy@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants