Tracking Issue for strict_provenance_lints #130351
Comments
RalfJung
added
T-lang
However, that discussion was about ptr-to- Nominating for t-lang to get a "temperature". |
RalfJung
added
the
I-lang-nominated
Would hosting this in |
|
Code that wants to be portable for CHERI likely has to set these lints to |
|
We discussed this in (excessive, as is our wont) length at the @rust-lang/lang meeting. The conclusions were:
|
Did anyone explain why? Suggesting people automatically migrate to the strict provenance conversions will type-check but probably add UB that is highly non-theoretical since #121282. Suggesting |
I'm afraid that signal will anyway diminish fairly quickly, as we have seen e.g. with |
|
This issue is tracking the factors that will cause the signal to diminish. If we care about the signal, we should be mindful to preserve it instead of creating more problems like was done with MaybeUninit. |
|
The documentation suggested it for arrays of But anyway, that was just an example, we don't have to litigate its details. The point is, I am not convinced we are fully in control of how that signal will diminish. Also, not having any |
traviscross
removed
the
I-lang-nominated
stabilize Strict Provenance and Exposed Provenance APIs Given that [RFC 3559](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html) has been accepted, t-lang has approved the concept of provenance to exist in the language. So I think it's time that we stabilize the strict provenance and exposed provenance APIs, and discuss provenance explicitly in the docs: ```rust // core::ptr pub const fn without_provenance<T>(addr: usize) -> *const T; pub const fn dangling<T>() -> *const T; pub const fn without_provenance_mut<T>(addr: usize) -> *mut T; pub const fn dangling_mut<T>() -> *mut T; pub fn with_exposed_provenance<T>(addr: usize) -> *const T; pub fn with_exposed_provenance_mut<T>(addr: usize) -> *mut T; impl<T: ?Sized> *const T { pub fn addr(self) -> usize; pub fn expose_provenance(self) -> usize; pub fn with_addr(self, addr: usize) -> Self; pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self; } impl<T: ?Sized> *mut T { pub fn addr(self) -> usize; pub fn expose_provenance(self) -> usize; pub fn with_addr(self, addr: usize) -> Self; pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self; } impl<T: ?Sized> NonNull<T> { pub fn addr(self) -> NonZero<usize>; pub fn with_addr(self, addr: NonZero<usize>) -> Self; pub fn map_addr(self, f: impl FnOnce(NonZero<usize>) -> NonZero<usize>) -> Self; } ``` I also did a pass over the docs to adjust them, because this is no longer an "experiment". The `ptr` docs now discuss the concept of provenance in general, and then they go into the two families of APIs for dealing with provenance: Strict Provenance and Exposed Provenance. I removed the discussion of how pointers also have an associated "address space" -- that is not actually tracked in the pointer value, it is tracked in the type, so IMO it just distracts from the core point of provenance. I also adjusted the docs for `with_exposed_provenance` to make it clear that we cannot guarantee much about this function, it's all best-effort. There are two unstable lints associated with the strict_provenance feature gate; I moved them to a new [strict_provenance_lints](rust-lang#130351) feature since I didn't want this PR to have an even bigger FCP. ;) `@rust-lang/opsem` Would be great to get some feedback on the docs here. :) Nominating for `@rust-lang/libs-api.` Part of rust-lang#95228. [FCP comment](rust-lang#130350 (comment))
Rollup merge of rust-lang#130350 - RalfJung:strict-provenance, r=dtolnay stabilize Strict Provenance and Exposed Provenance APIs Given that [RFC 3559](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html) has been accepted, t-lang has approved the concept of provenance to exist in the language. So I think it's time that we stabilize the strict provenance and exposed provenance APIs, and discuss provenance explicitly in the docs: ```rust // core::ptr pub const fn without_provenance<T>(addr: usize) -> *const T; pub const fn dangling<T>() -> *const T; pub const fn without_provenance_mut<T>(addr: usize) -> *mut T; pub const fn dangling_mut<T>() -> *mut T; pub fn with_exposed_provenance<T>(addr: usize) -> *const T; pub fn with_exposed_provenance_mut<T>(addr: usize) -> *mut T; impl<T: ?Sized> *const T { pub fn addr(self) -> usize; pub fn expose_provenance(self) -> usize; pub fn with_addr(self, addr: usize) -> Self; pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self; } impl<T: ?Sized> *mut T { pub fn addr(self) -> usize; pub fn expose_provenance(self) -> usize; pub fn with_addr(self, addr: usize) -> Self; pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self; } impl<T: ?Sized> NonNull<T> { pub fn addr(self) -> NonZero<usize>; pub fn with_addr(self, addr: NonZero<usize>) -> Self; pub fn map_addr(self, f: impl FnOnce(NonZero<usize>) -> NonZero<usize>) -> Self; } ``` I also did a pass over the docs to adjust them, because this is no longer an "experiment". The `ptr` docs now discuss the concept of provenance in general, and then they go into the two families of APIs for dealing with provenance: Strict Provenance and Exposed Provenance. I removed the discussion of how pointers also have an associated "address space" -- that is not actually tracked in the pointer value, it is tracked in the type, so IMO it just distracts from the core point of provenance. I also adjusted the docs for `with_exposed_provenance` to make it clear that we cannot guarantee much about this function, it's all best-effort. There are two unstable lints associated with the strict_provenance feature gate; I moved them to a new [strict_provenance_lints](rust-lang#130351) feature since I didn't want this PR to have an even bigger FCP. ;) `@rust-lang/opsem` Would be great to get some feedback on the docs here. :) Nominating for `@rust-lang/libs-api.` Part of rust-lang#95228. [FCP comment](rust-lang#130350 (comment))
stabilize Strict Provenance and Exposed Provenance APIs Given that [RFC 3559](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html) has been accepted, t-lang has approved the concept of provenance to exist in the language. So I think it's time that we stabilize the strict provenance and exposed provenance APIs, and discuss provenance explicitly in the docs: ```rust // core::ptr pub const fn without_provenance<T>(addr: usize) -> *const T; pub const fn dangling<T>() -> *const T; pub const fn without_provenance_mut<T>(addr: usize) -> *mut T; pub const fn dangling_mut<T>() -> *mut T; pub fn with_exposed_provenance<T>(addr: usize) -> *const T; pub fn with_exposed_provenance_mut<T>(addr: usize) -> *mut T; impl<T: ?Sized> *const T { pub fn addr(self) -> usize; pub fn expose_provenance(self) -> usize; pub fn with_addr(self, addr: usize) -> Self; pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self; } impl<T: ?Sized> *mut T { pub fn addr(self) -> usize; pub fn expose_provenance(self) -> usize; pub fn with_addr(self, addr: usize) -> Self; pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self; } impl<T: ?Sized> NonNull<T> { pub fn addr(self) -> NonZero<usize>; pub fn with_addr(self, addr: NonZero<usize>) -> Self; pub fn map_addr(self, f: impl FnOnce(NonZero<usize>) -> NonZero<usize>) -> Self; } ``` I also did a pass over the docs to adjust them, because this is no longer an "experiment". The `ptr` docs now discuss the concept of provenance in general, and then they go into the two families of APIs for dealing with provenance: Strict Provenance and Exposed Provenance. I removed the discussion of how pointers also have an associated "address space" -- that is not actually tracked in the pointer value, it is tracked in the type, so IMO it just distracts from the core point of provenance. I also adjusted the docs for `with_exposed_provenance` to make it clear that we cannot guarantee much about this function, it's all best-effort. There are two unstable lints associated with the strict_provenance feature gate; I moved them to a new [strict_provenance_lints](rust-lang/rust#130351) feature since I didn't want this PR to have an even bigger FCP. ;) `@rust-lang/opsem` Would be great to get some feedback on the docs here. :) Nominating for `@rust-lang/libs-api.` Part of rust-lang/rust#95228. [FCP comment](rust-lang/rust#130350 (comment))
This tracks the two lints associated with the strict provenance feature:
ascast from an integer to a pointer. It is better to usewith_exposed_provenanceinstead to make explicit what happens.ascast from a pointer to an integer. It is better to useexpose_provenanceinstead to make explicit what happens.I am not sure if having two lints here is really justified, IMO they could be merged into one -- not sure what that one should be called, though. Other than that, this seems like a useful lint to ensure the codebase follows strict provenance (or opts-out explicitly, via the methods mentioned above).
I am also not sure if this shouldn't maybe be a clippy lint instead of a rustc lint?
Cc @rust-lang/opsem
The text was updated successfully, but these errors were encountered: