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

Initial work on Miri permissive-exposed-provenance #95826

Merged
merged 1 commit into from
May 14, 2022

Conversation

carbotaniuman
Copy link
Contributor

Rustc portion of the changes for portions of a permissive ptr-to-int model for Miri. The main changes here are changing ptr_get_alloc and get_alloc_id to return an Option, and also making ptr-to-int casts have an expose side effect.

@rust-highfive
Copy link
Collaborator

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 8, 2022
@rust-highfive
Copy link
Collaborator

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 8, 2022
@carbotaniuman
Copy link
Contributor Author

r? @RalfJung

@rust-highfive rust-highfive assigned RalfJung and unassigned jackh726 Apr 8, 2022
@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot! I left a bunch of comments, but the general direction seems right to me.

Could you prepare a PR against Miri that does just the minimal thing to get Miri working again without any change in behavior? Then we wouldn't be under any pressure to get the Miri PR that actually does use the new features landed quickly, which would suit me well.

compiler/rustc_middle/src/mir/interpret/pointer.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/machine.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/cast.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/eval_context.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/memory.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/memory.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/memory.rs Outdated Show resolved Hide resolved
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Apr 19, 2022
…=oli-obk

Miri provenance cleanup

Reviewing rust-lang#95826 by `@carbotaniuman` made me realize that we could clean things up a little here.

`@carbotaniuman` please let me know if you're okay with landing this (it will create a lot of conflicts with your PR), or if you'd prefer incorporating the ideas from this PR into yours. I think we want to end up in a situation where the function you called `ptr_reify_alloc` returns just two things, a concrete tag and an offset. Getting an `AllocId` from a concrete tag should be infallible like now. However a concrete tag and `Tag` don't have to be the same type.

r? `@oli-obk`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Apr 19, 2022
…=oli-obk

Miri provenance cleanup

Reviewing rust-lang#95826 by ``@carbotaniuman`` made me realize that we could clean things up a little here.

``@carbotaniuman`` please let me know if you're okay with landing this (it will create a lot of conflicts with your PR), or if you'd prefer incorporating the ideas from this PR into yours. I think we want to end up in a situation where the function you called `ptr_reify_alloc` returns just two things, a concrete tag and an offset. Getting an `AllocId` from a concrete tag should be infallible like now. However a concrete tag and `Tag` don't have to be the same type.

r? ``@oli-obk``
@rust-log-analyzer

This comment has been minimized.

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it. :) Most of my comments are bikeshedding about names and comments.

compiler/rustc_const_eval/src/interpret/machine.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/cast.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/cast.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/cast.rs Outdated Show resolved Hide resolved
compiler/rustc_const_eval/src/interpret/operand.rs Outdated Show resolved Hide resolved
@RalfJung
Copy link
Member

Could you prepare a Miri PR that just does the minimal changes to make Miri work again as before after this PR landed?
Then we can land this before finishing the review on rust-lang/miri#2059, which I think would be good to decouple things.

@carbotaniuman
Copy link
Contributor Author

What's the miri_unleashed mean in src/test/ui/consts/miri_unleashed/ptr_arith.rs? It looks like the changes in a0a7c03 made it fail, but I'm not exactly sure why (or how it's even running a Miri test).

@rust-log-analyzer

This comment has been minimized.

@RalfJung
Copy link
Member

What's the miri_unleashed mean in src/test/ui/consts/miri_unleashed/ptr_arith.rs? It looks like the changes in a0a7c03 made it fail, but I'm not exactly sure why (or how it's even running a Miri test).

miri_unleashed mean we allow const fn to do everything.
So seeing the new errors you added in that test is exactly right. :) We previously took a bit longer to detect these casts, now we detect them earlier; that is good.

@RalfJung
Copy link
Member

r=me with the last two comment nits resolved and everything squashed into one commit.
(Unless @oli-obk has a suggestions for a better error we could throw in CTFE expose_ptr.)

FWIW, I don't actually know what the problem with function pointers is that you mentioned regarding ptr_from_addr_transmute, but we can figure that out while reviewing the Miri side of this.

@RalfJung
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented May 13, 2022

📌 Commit bd5fce6 has been approved by RalfJung

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 13, 2022
@bors
Copy link
Contributor

bors commented May 14, 2022

⌛ Testing commit bd5fce6 with merge 8019fa0...

@bors
Copy link
Contributor

bors commented May 14, 2022

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 8019fa0 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 14, 2022
@bors bors merged commit 8019fa0 into rust-lang:master May 14, 2022
@rustbot rustbot added this to the 1.62.0 milestone May 14, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (8019fa0): comparison url.

Summary: This benchmark run did not return any relevant results.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

@carbotaniuman carbotaniuman deleted the miri-permissive-provenance branch May 14, 2022 17:20
bors added a commit to rust-lang/miri that referenced this pull request May 23, 2022
Initial work on Miri permissive-exposed-provenance

Miri portions of the changes for portions of a permissive ptr-to-int model for Miri. This is more restrictive than what we currently have so it will probably need a flag once I figure out how to hook that up.

> This implements a form of permissive exposed-address provenance, wherein the only way to expose the address is with a cast to usize (ideally expose_addr). This is more restrictive than C in that stuff like reading the representation bytes (via unions, type-punning, transmute) does not expose the address, only expose_addr. This is less restrictive than C in that a pointer casted from an integer has union provenance of all exposed pointers, not any udi stuff.

There's a few TODOs here, namely related to `fn memory_read` and friends. We pass it the maybe/unreified provenance before `ptr_get_alloc` reifies it into a concrete one, so it doesn't have the `AllocId` (or the SB tag, but that's getting ahead of ourselves). One way this could be fixed is changing `ptr_get_alloc` and (`ptr_try_get_alloc_id` on the rustc side) to return a pointer with the tag fixed up. We could also take in different arguments, but I'm not sure what works best.

The other TODOs here are how permissive this model could be. This currently does not enforce that a ptr-to-int cast happens before the corresponding int-to-ptr (colloquial meaning of happens before, not atomic meaning). Example:

```
let ptr = 0x2000 as *const i32;
let a: i32 = 5;
let a_ptr = &a as *const i32;

// value is 0x2000;
a_ptr as usize;

println!("{}", unsafe { *ptr }); // this is valid
```

We also allow the resulting pointer to dereference different non-contiguous allocations (the "not any udi stuff" mentioned above), which I'm not sure if is allowed by LLVM.

This is the Miri side of rust-lang/rust#95826.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants