add vMVCC paper

[web.git] / personal / _posts / 2022-04-11-provenance-exposed.md

diff --git a/personal/_posts/2022-04-11-provenance-exposed.md b/personal/_posts/2022-04-11-provenance-exposed.md
index 39237ae17b6262853f99e26fae4a8c8144c20ff8..6d0d7d35f5bc4083ff941f575178963f9f5b673d 100644 (file)
--- a/personal/_posts/2022-04-11-provenance-exposed.md
+++ b/personal/_posts/2022-04-11-provenance-exposed.md
@@ -1,6 +1,6 @@
 ---
 title: "Pointers Are Complicated III, or: Pointer-integer casts exposed"
 ---
 title: "Pointers Are Complicated III, or: Pointer-integer casts exposed"

-categories: rust research
+categories: rust research programming

 license: CC BY-SA 4.0
 license-url: https://creativecommons.org/licenses/by-sa/4.0/
 reddit: /rust/comments/u1bbqn/pointers_are_complicated_iii_or_pointerinteger/
 license: CC BY-SA 4.0
 license-url: https://creativecommons.org/licenses/by-sa/4.0/
 reddit: /rust/comments/u1bbqn/pointers_are_complicated_iii_or_pointerinteger/


@@ -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.
 **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
 
 
 ## 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,
 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.
 
 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.