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

[Gankra]

This issue is part of the Strict Provenance Experiment - #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.

rust/library/core/src/ptr/mut_ptr.rs

Lines 197 to 205 in bb5c437

	pub fn with_addr(self, addr: usize) -> Self
	where
	T: Sized,
	{
	// FIXME(strict_provenance_magic): I am magic and should be a compiler intrinsic.
	//
	// In the mean-time, this operation is defined to be "as if" it was
	// a wrapping_offset, so we can emulate it as such. This should properly
	// restore pointer provenance even under today's compiler.

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.

rust/library/core/src/ptr/mut_ptr.rs

Lines 201 to 218 in 261823e

	/// On most platforms this will produce a value with the same bytes as the original
	/// pointer, because all the bytes are dedicated to describing the address.
	/// Platforms which need to store additional information in the pointer may
	/// perform a change of representation to produce a value containing only the address
	/// portion of the pointer. What that means is up to the platform to define.
	///
	/// This API and its claimed semantics are part of the Strict Provenance experiment, and as such
	/// might change in the future (including possibly weakening this so it becomes wholly
	/// equivalent to `self as usize`). See the [module documentation][crate::ptr] for details.
	#[must_use]
	#[inline(always)]
	#[unstable(feature = "strict_provenance", issue = "95228")]
	pub fn addr(self) -> usize {
	// FIXME(strict_provenance_magic): I am magic and should be a compiler intrinsic.
	// SAFETY: Pointer-to-integer transmutes are valid (if you are okay with losing the
	// provenance).
	unsafe { mem::transmute(self.cast::<()>()) }
	}

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 #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 llvm/llvm-project#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.