From: Ralf Jung Date: Wed, 14 Sep 2022 07:55:15 +0000 (+0200) Subject: tweak the update X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/cd1d77b71a948549ede3af63debdc118955b11fc tweak the update --- diff --git a/personal/_posts/2022-04-11-provenance-exposed.md b/personal/_posts/2022-04-11-provenance-exposed.md index 39237ae..709dbc6 100644 --- a/personal/_posts/2022-04-11-provenance-exposed.md +++ b/personal/_posts/2022-04-11-provenance-exposed.md @@ -280,8 +280,10 @@ A [first careful step](https://github.com/rust-lang/rust/pull/95547) has recentl **Update (2022-09-14):** After a lot more discussion, the current model pursued by the Unsafe Code Guidelines WG is to say that pointer-to-integer transmutation is permitted, but just strips provenance without exposing it. That means the program with the casts replaced by transmutation is UB, because the `ptr` it ends up dereferencing has invalid provenance. However, the transmutation itself is not UB. -Basically, pointer-to-integer transmutation is equivalent to [the `addr` method](https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.addr), with all its caveats -- in particular, transmuting a pointer to an integer and back is like calling `addr` and then calling [`ptr::invalid`](https://doc.rust-lang.org/nightly/std/ptr/fn.invalid.html); that is not a lossless round-trip. -This model has some nice properties that help compiler optimizations (such as removing unnecessary store-load round-trips). **/Update** +Basically, pointer-to-integer transmutation is equivalent to [the `addr` method](https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.addr), with all its caveats -- in particular, transmuting a pointer to an integer and back is like calling `addr` and then calling [`ptr::invalid`](https://doc.rust-lang.org/nightly/std/ptr/fn.invalid.html). +That is a *lossy* round-trip: it loses provenance information, making the resulting pointer invalid to dereference. +It is lossy even if we use a regular integer-to-pointer cast (or `from_exposed_addr`) for the conversion back to a pointer, since the original provenance might never have been exposed. +Compared to declaring the transmutation itself UB, this model has some nice properties that help compiler optimizations (such as removing unnecessary store-load round-trips). **/Update** ## A new hope for Rust @@ -289,7 +291,7 @@ All in all, while the situation may be very complicated, I am actually more hope The three core pillars of this approach are: - making pointer-integer casts "expose" the pointer's provenance, - offering `ptr.addr()` to learn a pointer's address *without* exposing its provenance, -- and disallowing pointer-integer transmutation round-trips. +- and making pointer-integer transmutation round-trips lossy (such that the resulting pointer cannot be dereferenced). Together, they imply that we can optimize "nice" code (that follows Strict Provenance, and does not "expose" or use integer-pointer casts) perfectly, without any risk of breaking code that does use pointer-integer round-trips. In the easiest possible approach, the compiler can simply treat pointer-integer and integer-pointer casts as calls to some opaque external function.