Initial work on Miri permissive-exposed-provenance #95826
Conversation
|
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
added
the
T-compiler
|
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
r? @RalfJung |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
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.
…=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`
…=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``
carbotaniuman
force-pushed
the
miri-permissive-provenance
branch
from
e91049c
to
89ece78
Compare
This comment has been minimized.
This comment has been minimized.
|
Could you prepare a Miri PR that just does the minimal changes to make Miri work again as before after this PR landed? |
carbotaniuman
force-pushed
the
miri-permissive-provenance
branch
from
390d53e
to
a0a7c03
Compare
|
What's the |
This comment has been minimized.
This comment has been minimized.
miri_unleashed mean we allow |
|
r=me with the last two comment nits resolved and everything squashed into one commit. 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. |
carbotaniuman
force-pushed
the
miri-permissive-provenance
branch
from
c4a9cb1
to
bd5fce6
Compare
|
@bors r+ |
|
📌 Commit bd5fce6 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
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 |
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.
Rustc portion of the changes for portions of a permissive ptr-to-int model for Miri. The main changes here are changing
ptr_get_allocandget_alloc_idto return an Option, and also making ptr-to-int casts have an expose side effect.