Skip to content

Commit 332e566

Browse files
Pull in previously proposed strict provenance text
1 parent 90aa1bb commit 332e566

File tree

1 file changed

+29
-23
lines changed

1 file changed

+29
-23
lines changed

posts/2025-01-09-Rust-1.84.0.md

Lines changed: 29 additions & 23 deletions
Original file line numberDiff line numberDiff line change
@@ -74,29 +74,35 @@ and the [stabilization report](https://github.com/rust-lang/rust/pull/130654)
7474

7575
[Crater]: https://github.com/rust-lang/crater/
7676

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).
100106

101107
### Stabilized APIs
102108

0 commit comments

Comments
 (0)