Using `pointer::add` with volatile memory

[Darksonn]

When working with volatile memory it's common to do so entirely using raw pointers, making sure to never create a reference so that the volatile memory never gets considered a real allocation in the opsem.

The pointer::add method has these safety requirements:

If the computed offset is non-zero, then self must be derived from a pointer to some allocation, and the entire memory range between self and the result must be in bounds of that allocation. In particular, this range must not “wrap around” the edge of the address space.

The point of never creating a reference to the memory is to avoid assuming that there is a real allocation there. This is so that it's illegal for LLVM to introduce a spurious read to the volatile memory. From my reading of pointer::add it seems the same applies to that method.

However, this puts us in a somewhat tricky situation. It means that &raw mut (*volatile_ptr).field does not work for getting a pointer to a field of a struct in volatile memory, and the layout of volatile memory is often described by referring to an equivalent C struct. This is a challenge since there are no convenient alternatives to &raw mut.

[RalfJung]

That's a good point.

IIRC, LLVM will never deduce dereferenceability from inbounds alone. In fact it cannot because it suffices for the offset to be inbounds of a dead allocation. So this is a Rust-level problem only.

In Rust we so far have not distinguished between memory that is dereferenceable in the sense that spurious loads/stores are allowed, and memory that is inbounds in the sense required for ptr::offset/ptr::add. I was hoping we could get around that. But maybe we cannot...

[RalfJung]

The easiest fix is to follow what LLVM does and say that offset/add may be used on pointers with the provenance of a dead allocation, as long as they remain inbounds of that allocation. Then we can claim that there's a dead allocation for each MMIO region.

Or we could say that the AM has a dedicated notion of "MMIO allocations" whose address and size has to satisfy the usual properties, but which aren't actually addressable memory (so in the mapping to LLVM we'd model these as dead allocations).

Either way that means provenance still matters for these MMIO pointers, so one has to be a bit careful about how to create them: a pointer created by an int2ptr cast (or with_exposed_provenance) has a single provenance that all pointers derived from it inherit, and all the inbounds arithmetic done on them has to all be inbounds of the same dead allocation. Allocations cannot be larger than isize::MAX, so if the inbounds arithmetics are too far apart from each other there's no single big allocation they could possibly all be a part of, and the compiler could notice that. It's better to use separate int2ptr casts for each separate region, so only the pointers for a single region have to all be inbounds of a single (dead) allocation.

If we go for the concept of an "MMIO allocation", that would mesh well with the old discussions around a replacement for with_exposed_provenance for fixed-address MMIO regions: we could have an operation to create such an MMIO allocation at a given address and size. It has to be disjoint from all memory that the Rust AM currently uses. The size must not exceed isize::MAX, the address must not be null, and addr + size must not overflow usize. (This is to uphold the basic properties of allocations, it's not clear to me that we can relax this.) The returned pointer has a fresh provenance on which inbounds pointer arithmetic may be performed (using the given allocation bounds), and which may be used for volatile reads/writes, but no Rust-level reads or writes may be performed on that pointer nor any reference created from it (with the usual exception for ZST).