credit where credit is due

[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 317cc3039649b0a658efef22cd82cbab636c4508..b37344cc8a3715577b34dedb9a2cee828b9444aa 100644 (file)
--- a/personal/_posts/2022-04-11-provenance-exposed.md
+++ b/personal/_posts/2022-04-11-provenance-exposed.md
@@ -17,7 +17,7 @@ There's a lot of information packed into this post, so better find a comfortable
 
 In case you don't know what I mean by "pointer provenance", you can either read that previous blog post or the [Strict Provenance documentation](https://doc.rust-lang.org/nightly/core/ptr/index.html#provenance).
 The gist of it is that a pointer consists not only of the address that it points to in memory, but also of its *provenance*: an extra piece of "shadow state" that is carried along with each pointer and that tracks which memory the pointer has permission to access and when.
 
 In case you don't know what I mean by "pointer provenance", you can either read that previous blog post or the [Strict Provenance documentation](https://doc.rust-lang.org/nightly/core/ptr/index.html#provenance).
 The gist of it is that a pointer consists not only of the address that it points to in memory, but also of its *provenance*: an extra piece of "shadow state" that is carried along with each pointer and that tracks which memory the pointer has permission to access and when.

-This is required to make sense of restrictions like "pointer arithmetic can never be used to construct a pointer that is valid for a different allocation than the one it started out in" (even with operations like Rust's [`wrapping_offset`](https://doc.rust-lang.org/std/primitive.pointer.html#method.wrapping_offset) that *do* allow out-of-bounds pointer arithmetic), or "use-after-free is Undefined Behavior, even if you checked that there is a new allocation at the same address as the old one".
+This is required to make sense of restrictions like "use-after-free is Undefined Behavior, even if you checked that there is a new allocation at the same address as the old one".

 Architectures like CHERI make this "shadow state" explicit (pointers are bigger than usual so that they can explicitly track which part of memory they are allowed to access),
 but even when compiling for AMD64 CPUs, compilers act "as if" pointers had such extra state -- it is part of the specification, part of the Abstract Machine, even if it is not part of the target CPU.
 
 Architectures like CHERI make this "shadow state" explicit (pointers are bigger than usual so that they can explicitly track which part of memory they are allowed to access),
 but even when compiling for AMD64 CPUs, compilers act "as if" pointers had such extra state -- it is part of the specification, part of the Abstract Machine, even if it is not part of the target CPU.
 


@@ -78,7 +78,7 @@ static int uwu(int *restrict x, int *restrict y) {
 
   int *y2 = y-1;
   uintptr_t y2addr = (uintptr_t)y2;
 
   int *y2 = y-1;
   uintptr_t y2addr = (uintptr_t)y2;

-  int *ptr = (int*)y2addr;
+  int *ptr = (int*)y2addr; // <-- using y2addr

   *ptr = 1;
 
   return *x;
   *ptr = 1;
 
   return *x;


@@ -104,12 +104,12 @@ static int uwu(int *restrict x, int *restrict y) {
   int *ptr = (int*)y2addr;
   *ptr = 1;
 
   int *ptr = (int*)y2addr;
   *ptr = 1;
 

-  return 0;
+  return 0; // <-- hard-coded return value

 }
 
 int main() {
 }
 
 int main() {

-  int i = 0;
-  int res = uwu(&i, &i);
+  int i[2] = {0, 0};
+  int res = uwu(&i[0], &i[1]);

   // Now this prints 0!
   printf("%d\n", res);
 }
   // Now this prints 0!
   printf("%d\n", res);
 }


@@ -196,10 +196,12 @@ This may sound like bad news for low-level coding tricks like pointer tagging (s
 Do we have to optimize this code less just because of corner cases like the above?
 As it turns out, no we don't -- there are some situations where it is perfectly fine to do a pointer-integer cast *without* having the "exposure" side-effect.
 Specifically, this is the case if we never intend to cast the integer back to a pointer!
 Do we have to optimize this code less just because of corner cases like the above?
 As it turns out, no we don't -- there are some situations where it is perfectly fine to do a pointer-integer cast *without* having the "exposure" side-effect.
 Specifically, this is the case if we never intend to cast the integer back to a pointer!

-That might seem like a niche case, but it turns out that most of the time, we can avoid 'bare' integer-pointer casts, and instead use an operation like [`with_addr`](https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.with_addr) that explicitly specifies which provenance to use for the newly created pointer.
+That might seem like a niche case, but it turns out that most of the time, we can avoid 'bare' integer-pointer casts, and instead use an operation like [`with_addr`](https://doc.rust-lang.org/nightly/std/primitive.pointer.html#method.with_addr) that explicitly specifies which provenance to use for the newly created pointer.[^with_addr]

 This is more than enough for low-level pointer shenanigans like pointer tagging, as [Gankra demonstrated](https://gankra.github.io/blah/tower-of-weakenings/#strict-provenance-no-more-getting-lucky).
 Rust's [Strict Provenance experiment](https://doc.rust-lang.org/nightly/std/ptr/index.html#strict-provenance) aims to determine whether we can use operations like `with_addr` to replace basically all integer-pointer casts.
 
 This is more than enough for low-level pointer shenanigans like pointer tagging, as [Gankra demonstrated](https://gankra.github.io/blah/tower-of-weakenings/#strict-provenance-no-more-getting-lucky).
 Rust's [Strict Provenance experiment](https://doc.rust-lang.org/nightly/std/ptr/index.html#strict-provenance) aims to determine whether we can use operations like `with_addr` to replace basically all integer-pointer casts.
 

+[^with_addr]: `with_addr` has been unstably added to the Rust standard library very recently. Such an operation has been floating around in various discussions in the Rust community for quite a while, and it has even made it into [an academic paper](https://iris-project.org/pdfs/2022-popl-vip.pdf) under the name of `copy_alloc_id`. Who knows, maybe one day it will find its way into the C standard as well. :)
+

 As part of Strict Provenance, Rust now has a second way of casting pointers to integers, `ptr.addr()`, which does *not* "expose" the permission of the underlying pointer, and hence can be treated like a pure operation![^experiment]
 We can do shenanigans on the integer representation of a pointer *and* have all these juicy optimizations, as long as we don't expect bare integer-pointer casts to work.
 As a bonus, this also makes Rust work nicely on CHERI *without* a 128bit wide `usize`, and it helps Miri, too.
 As part of Strict Provenance, Rust now has a second way of casting pointers to integers, `ptr.addr()`, which does *not* "expose" the permission of the underlying pointer, and hence can be treated like a pure operation![^experiment]
 We can do shenanigans on the integer representation of a pointer *and* have all these juicy optimizations, as long as we don't expect bare integer-pointer casts to work.
 As a bonus, this also makes Rust work nicely on CHERI *without* a 128bit wide `usize`, and it helps Miri, too.


@@ -295,7 +297,8 @@ This is the entire reason why all of this "untagged pointer" mess exists.
 Under this brave new world, I can entirely ignore pointer-integer round-trips when designing memory models for Rust.
 Once that design is done, support for pointer-integer round-trips can be added as follows:
 - When a pointer is cast to an integer, its provenance (whatever information it is that the model attaches to pointers -- in Stacked Borrows, this is called the pointer's *tag*) is marked as "exposed".
 Under this brave new world, I can entirely ignore pointer-integer round-trips when designing memory models for Rust.
 Once that design is done, support for pointer-integer round-trips can be added as follows:
 - When a pointer is cast to an integer, its provenance (whatever information it is that the model attaches to pointers -- in Stacked Borrows, this is called the pointer's *tag*) is marked as "exposed".

-- When an integer is cast to a pointer, we *guess* the provenance that the new pointer should have from among all the provenances that have been previously marked as "exposed". (And I mean *all* of them, not just the ones that have been exposed "at the same address" or anything like that. People will inevitably do imperfect round-trips where the integer is being offset before being cast back to a pointer, and we should support that. As far as I know, this doesn't really cost us anything in terms of optimizations.)
+- When an integer is cast to a pointer, we *guess* the provenance that the new pointer should have from among all the provenances that have been previously marked as "exposed".
+  (And I mean *all* of them, not just the ones that have been exposed "at the same address" or anything like that. People will inevitably do imperfect round-trips where the integer is being offset before being cast back to a pointer, and we should support that. As far as I know, this doesn't really cost us anything in terms of optimizations.)

 
 This "guess" does not need to be described by an algorithm.
 Through the magic that is formally known as [angelic non-determinism](https://en.wikipedia.org/wiki/Angelic_non-determinism), we can just wave our hands and say "the guess will be maximally in the programmer's favor": if *any* possible choice of (previously exposed) provenance makes the program work, then that is the provenance the new pointer will get.
 
 This "guess" does not need to be described by an algorithm.
 Through the magic that is formally known as [angelic non-determinism](https://en.wikipedia.org/wiki/Angelic_non-determinism), we can just wave our hands and say "the guess will be maximally in the programmer's favor": if *any* possible choice of (previously exposed) provenance makes the program work, then that is the provenance the new pointer will get.


@@ -315,7 +318,8 @@ And who knows, maybe there *is* a clever way that Miri can actually get reasonab
 It doesn't have to be perfect to be useful.
 
 What I particularly like about this approach is that it makes pointer-integer round-trips a purely local concern.
 It doesn't have to be perfect to be useful.
 
 What I particularly like about this approach is that it makes pointer-integer round-trips a purely local concern.

-With an approach like Stacked Borrows "untagged pointers", *every* memory operation has to define how it handles such pointers -- complexity increases globally, and even when reasoning about Strict Provenance code we have to keep in mind that some pointers in other parts of the program might be "untagged".
+With an approach like Stacked Borrows "untagged pointers", *every* memory operation has to define how it handles such pointers.
+Complexity increases globally, and even when reasoning about Strict Provenance code we have to keep in mind that some pointers in other parts of the program might be "untagged".

 In contrast, this "guessing maximally in your favor"-based approach is entirely local; code that does not syntactically contain exposing pointer-integer or integer-pointer casts can literally forget that such casts exist at all.
 This is true both for programmers thinking about their `unsafe` code, and for compiler authors thinking about optimizations.
 Compositionality at its finest!
 In contrast, this "guessing maximally in your favor"-based approach is entirely local; code that does not syntactically contain exposing pointer-integer or integer-pointer casts can literally forget that such casts exist at all.
 This is true both for programmers thinking about their `unsafe` code, and for compiler authors thinking about optimizations.
 Compositionality at its finest!


@@ -338,7 +342,11 @@ However, if/when a more precise model of C with `restrict` emerges, I don't thin
 The "udi" part of the name means "user disambiguation", and is basically the mechanism by which an integer-pointer cast in C "guesses" the provenance it has to pick up.
 The details of this are complicated, but the end-to-end effect is basically exactly the same as in the "best possible guess" model I have described above!
 Here, too, my vision for Rust aligns very well with the direction C is taking.
 The "udi" part of the name means "user disambiguation", and is basically the mechanism by which an integer-pointer cast in C "guesses" the provenance it has to pick up.
 The details of this are complicated, but the end-to-end effect is basically exactly the same as in the "best possible guess" model I have described above!
 Here, too, my vision for Rust aligns very well with the direction C is taking.

-(The set of valid guesses in C is just a lot more restricted since they do not have `wrapping_offset`. That means they can actually feasibly give an algorithm for how to do the guessing.)
+(The set of valid guesses in C is just a lot more restricted since they do not have `wrapping_offset`, and the model does not cover `restrict`.
+That means they can actually feasibly give an algorithm for how to do the guessing.
+They don't have to invoke scary terms like "angelic non-determinism", but the end result is the same -- and to me, the fact that it is equivalent to angelic non-determinism is what justifies this as a reasonable semantics.
+Presenting this as a concrete algorithm to pick a suitable provenance is then just a stylistic choice.
+Kudos go to Michael Sammler for opening my eyes to this interpretation of "user disambiguation".)

 
 What is left is the question of how to handle pointer-integer transmutation, and this is where the roads are forking.
 PNVI-ae-udi explicitly says loading from a union field at integer type exposes the provenance of the pointer being loaded, if any.
 
 What is left is the question of how to handle pointer-integer transmutation, and this is where the roads are forking.
 PNVI-ae-udi explicitly says loading from a union field at integer type exposes the provenance of the pointer being loaded, if any.


@@ -426,6 +434,9 @@ Here's the list of open problems I am aware of:
 So far, this all applies to LLVM as a Rust and C backend equally, so I don't think there are any good alternatives.
 On the plus side, adapting this strategy for `inttoptr` and `ptrtoint` means that the recent LLVM ["Full Restrict Support"](https://lists.llvm.org/pipermail/llvm-dev/2019-March/131127.html) can also handle pointer-integer round-trips "for free"!
 
 So far, this all applies to LLVM as a Rust and C backend equally, so I don't think there are any good alternatives.
 On the plus side, adapting this strategy for `inttoptr` and `ptrtoint` means that the recent LLVM ["Full Restrict Support"](https://lists.llvm.org/pipermail/llvm-dev/2019-March/131127.html) can also handle pointer-integer round-trips "for free"!
 

+Adding `with_addr`/`copy_alloc_id` to LLVM is not strictly necessary, since it can be implemented with `getelementptr` (without `inbounds`).
+However, optimizations don't seem to always deal well with that pattern, so it might still be a good idea to add this as a primitive operation to LLVM.
+

 Where things become more subtle is around pointer-integer transmutation.
 If LLVM wants to keep doing replacement of `==`-equal integers (which I strongly assume to be the case), *something* needs to give: my first example, with casts replaced by transmutation, shows a miscompilation.
 If we focus on doing an `i64` load of a pointer value (e.g. as in the LLVM IR produced by `transmute_union`, or pointer-based transmutation in Rust), what are the options?
 Where things become more subtle is around pointer-integer transmutation.
 If LLVM wants to keep doing replacement of `==`-equal integers (which I strongly assume to be the case), *something* needs to give: my first example, with casts replaced by transmutation, shows a miscompilation.
 If we focus on doing an `i64` load of a pointer value (e.g. as in the LLVM IR produced by `transmute_union`, or pointer-based transmutation in Rust), what are the options?