[strict provenance] Make The strict_provenance APIs Actual Compiler Magic?

[Gankra]

This issue is part of the Strict Provenance Experiment - https://github.com/rust-lang/rust/issues/95228

I left a few little FIXME(strict_provenance_magic) comments around core::ptr to indicate places that might want to become a compiler intrinsic for... Reasons. Currently all of these operations function but it's possible they can function "better" or somehow power better checking/analysis with builtin support.

In particular you probably want with_addr as some kind of instrinsic because the naive impl does a bunch of faffing around when on most platforms it's usize as *mut T and on CHERI this is literally cheri_address_set.

https://github.com/rust-lang/rust/blob/bb5c437a2ce9ccf2204c974300c5ea9eb32d3635/library/core/src/ptr/mut_ptr.rs#L197-L205

This discussion is 100% "above my pay grade", I cannot provide any more insight.

[RalfJung]

Yeah, the wrapping_offset stuff is a somewhat roundabout way of expressing intent. Sadly LLVM doesn't really have a better way, either, so we'd have to start by convincing them to add a suitable with_addr-like operation.

[NCGThompson]

The current implementation of addr() is a transmutation, while the documentation says that platforms may change the representation if a pointer contains additional information, which seems to be contradictory.

https://github.com/rust-lang/rust/blob/261823eee7021ae24e282e2ca28dbbd3d287b10f/library/core/src/ptr/mut_ptr.rs#L201-L218

This would be fixed by fixing this issue. For currently supported targets, there is no difference between a pointer and its integer representation. However, if I understand correctly (probably not), this may become a problem for arm64e-apple-darwin and arm64e-apple-ios.

[RalfJung]

The current implementation of addr() is a transmutation, while the documentation says that platforms may change the representation if a pointer contains additional information, which seems to be contradictory.

The emphasis is on may. So it's not contradictory. It's just libcore making use of the fact that it is bundled with the compiler so we know we can do things that we don't allow users to do.

Pointer authentication is entirely orthogonal to these questions; the "address" does include the authentication tag on those platforms. Basically these are just allocations that live at strangely high addresses, as far as Rust is concerned.

[RalfJung]

FWIW I am removing these FIXMEs in https://github.com/rust-lang/rust/pull/130350. Right now I don't think there's a fundamental reason why these things have to be intrinsics, though with_addr could be expressed more efficiently as an intrinsic.

[scottmcm]

Can you elaborate on which kind of "more efficiently" you're thinking here, Ralf?

In terms of "well it'd be nice to not have to lower to ptr2int in LLVM", or something MIR-side?

cc also https://github.com/llvm/llvm-project/pull/98649 which might help some cases of this.

[RalfJung]

with_addr is kind of silly right now, doing a bunch of arithmetic that exactly cancels out -- the operation doesn't actually need any arithmetic and hence ideally would be expressed directly as an intrinsic.