@@ -74,29 +74,35 @@ and the [stabilization report](https://github.com/rust-lang/rust/pull/130654)
74
74
75
75
[ Crater ] : https://github.com/rust-lang/crater/
76
76
77
- ### Strict provenance APIs stabilized
78
-
79
- Pointers (this includes values of reference type) in Rust have two components.
80
-
81
- * The pointer's "address" says where in memory the pointer is currently pointing.
82
- * The pointer's "provenance" says where and when the pointer is allowed to access memory.
83
-
84
- In 1.84, a number of standard library functions are stabilized to permit
85
- explicitly manipulating the address and provenance parts of pointers, avoiding
86
- integer-to-pointer casts to side-step the inherent ambiguity of that operation.
87
- This benefits compiler optimizations, and it is pretty much a requirement for
88
- using tools like [ Miri] ( https://github.com/rust-lang/miri ) and architectures
89
- like [ CHERI] ( https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ ) that aim
90
- to detect and diagnose pointer misuse.
91
-
92
- We recommend that code generally be written against the strict provenance APIs
93
- when it needs to manipulate pointers. Rust code that doesn't cast integers to
94
- pointers is already staying within the bounds of strict provenance, though the
95
- usage of these APIs can make the programmer's intent clearer to tooling.
96
-
97
- See the [ documentation] ( https://doc.rust-lang.org/nightly/std/ptr/index.html#strict-provenance )
98
- for more details on these APIs. For more background, [ RFC 3559] ( https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html )
99
- lays out the rationale for having provenance.
77
+ ### Strict provenance APIs
78
+
79
+ In Rust, [ pointers are not simply an “integer” or
80
+ “address”] ( https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html ) . For
81
+ instance, it’s uncontroversial to say that a Use After Free is clearly
82
+ Undefined Behavior, even if you “get lucky” and the freed memory gets
83
+ reallocated before your read/write. It is also uncontroversial that writing
84
+ through a pointer derived from an ` &i32 ` reference is Undefined Behavior, even
85
+ if writing to the same address via a different pointer is legal. The underlying
86
+ pattern here is that * the way a pointer is computed matters* , not just the
87
+ address that results from this computation. For this reason, we say that
88
+ pointers have ** provenance** : to fully characterize pointer-related Undefined
89
+ Behavior in Rust, we have to know not only the address the pointer points to,
90
+ but also track which other pointer(s) it is "derived from".
91
+
92
+ Most of the time, programmers do not need to worry much about provenance, and
93
+ it is very clear how a pointer got derived. However, when casting pointers to
94
+ integers and back, the provenance of the resulting pointer is underspecified.
95
+ With this release, Rust is adding a set of APIs that can in many cases replace
96
+ the use of integer-pointer-casts, and therefore avoid the ambiguities inherent
97
+ to such casts. In particular, the pattern of using the lowest bits of an
98
+ aligned pointer to store extra information can now be implemented without ever
99
+ casting a pointer to an integer or back. This makes the code easier to reason
100
+ about, easier to analyze for the compiler, and also benefits tools like
101
+ [ Miri] ( https://github.com/rust-lang/miri ) and architectures like
102
+ [ CHERI] ( https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ ) that aim to
103
+ detect and diagnose pointer misuse.
104
+
105
+ For more details, see the standard library [ documentation on provenance] ( https://doc.rust-lang.org/std/ptr/index.html#provenance ) .
100
106
101
107
### Stabilized APIs
102
108
0 commit comments