Hi!

I am maintaining rust code that provides direct access to the linux syscalls. In a lot of scenarios the linux kernel uses u64 for pointers to make sure 32bit/64bit mixed systems have a single ABI (kernel calls workarounds for it 'compat'-mode). In other scenarios, unsigned long or u64 basically contain unions of lots of different argument options. If I understood correctly, there is no inherent conflict with strict provenance, though I struggle to properly implement it.

I understand that the recommendation is to make FFI calls take a pointer-type as argument, even if the other side takes an unsigned long (or similar). However, what if the full set of possible arguments is either too big or unknown? In my case, I have syscall0() up to syscall6() which corresponds to the libc syscall(...) function. They are implemented in rust with inline assembly and simply take 0 to 6 usize arguments. No external linkage required at all. On top, I have typed per-syscall wrappers. But under strict provenance, I cannot implement the typed-wrappers but have to resort to expose_addr(), even though I never use from_exposed_addr(). I want to avoid implementing the syscall stubs in C or other FFI. This is pure rust (minus inline assembly).

My ideal solution would be a way to take a pointer in rust and format it as an integer of my choice. I am fine with it still being a pointer, but I want it to be formatted like a u64 (or another integer of my choice bigger than usize, depending on platform). I can then pass it to the syscall and be done with it. Alternatively, there must be some state-change that miri/etc. apply to a pointer passed through FFI, and I would be fine calling the same function on that pointer. Something like publish_addr() that tells miri/etc. to assume the address was exposed via FFI.

Note that formatting the value as union does not work here. For instance, assume a big-endian 32bit architecture with a 64bit syscall argument. The union would look like this:

#[repr(C)]
union Arg {
    ptr: *mut core::ffi::c_void,
    int: u64,
}

Assigning a pointer to Arg.ptr would differ from assigning its address to Arg.int, since on big-endian the 32bit Arg.ptr would be aligned to the start of the union, while in Arg.int the lower 32bits would be at the end of the union (I could use ptrs: [*mut core::ffi::c_void; 2] and store in the right bucket, but not sure that is the right solution?).

So I am a bit out of ideas what to do and looking for help! Thanks David

I noticed that expose_addr is marked as #[must_use] even though in some cases the returned value won't be used.

My use case involves using mmap to get a large chunk of memory with a specific alignment so that any references to values placed in that memory can be used to compute the start address of that memory (where some metadata is located and from which relative offsets can be added).

So in this case, expose_addr is used once after getting the memory from mmap and later the address to provide to from_exposed_addr is independently computed.

Syncs with https://github.com/rust-lang/rust/pull/97710

Once https://github.com/rust-lang/miri/issues/2133 is complete, this then correctly implements the distinction between addr and expose_addr, as well as between invalid and from_exposed_addr. Misuses of these APIs are detected by Miri, and ptr-int-ptr roundtrips only work if you use expose_addr and from_exposed_addr. :)

As a polyfill, it makes sense for this crate to try to support older rustc as much as possible. I was able to get it back to Rust 1.31 without any compromises, but any older would have to deal with conditional support for const fn.

We have strict provenance APIs for AtomicPtr in the stdlib, but not in sptr.

• AtomicPtr::fetch_and
• AtomicPtr::fetch_or
• AtomicPtr::fetch_xor
• AtomicPtr::fetch_byte_add
• AtomicPtr::fetch_byte_sub
• AtomicPtr::fetch_ptr_add
• AtomicPtr::fetch_ptr_sub

I think its reasonably likely that the last two get renamed, since the name is rather misleading at the moment. It might be worth leaving them out, since they can be replicated in terms of fetch_byte_{add,sub} anyway.

I don't really know how to shim this best. The most "accurate" way would be in terms of fetch_update that uses with_addr in it's closure. But this would... kinda destroy performance. An approach that special-cases miri might be worth using.

I'll try to PR these next weekend I guess, but if someone else feels like taking it they should feel free.