[strict provenance] Provide a way to "create allocations at a fixed address" #98593
Comments
RalfJung
added
T-lang
|
Until such a function exists, one can use |
|
One thing I'd like to mention at the start is that hardware addresses should not be modeled as "owned" by anything inside Rust. They're generally volatile, and generally what you read from them might change without Rust doing anything on its end. At best we should think of them as Rust sharing the address with some external force. Because of this, I think a name like "alloc" would be a misstep. People have the notion/understanding that when you alloc some memory you own it while it's live, and then you (or some drop glue) explicitly does a "free", and and it's dead. That's not really how hardware access works at all, so for a new situation we pick a new name. Particularly, lots of existing and well working rust code doesn't bother with a "free" step at all when using hardware pointers. You just make up a pointer that you know is good, you read or write, and then you forget the pointer, and someone else might even be holding a pointer to that same location while you're doing all this, and it's all fine. If a person wants to build an ownership-style API on top of this using the borrow checker they can do that (there's several such examples), but that's separate from the base requirements of the abstract machine interacting with the hardware. |
|
Perhaps directly labelling these addresses as volatile might be the best way to go? This would also help for FFI as well, since you could make the distinction between an address for something that is "owned" inside the Rust code until passed back via FFI, or something that could concurrently be modified outside of Rust, by hardware or another thread. |
|
@Lokathor what you say also confirms my thoughts above that we want to use the same provenance for all calls to this function, and not generate a fresh one. That provenance is assumed to be exposed from the start, so it is basically public and can change any time control is given to other code (including via another thread). Using volatile accesses is a separate concern; Rust assumes for all pointers that if you do 2 non-atomic loads immediately after one another, they will give the same result -- there is no good way to opt-out of that assumption just for a specific provenance; this needs a more explicit marker at the relevant access. (I.e., making it volatile.)
There is no such thing as a volatile address. Being volatile is the property of an access. There are plenty of discussions around the semantics of volatile, their interaction with reference types, and so on; I would like to keep them out of here. This thread is solely about the name, signature, and provenance interaction of the function that is intended to replace those casts. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
There are plenty of cases where you want access at a particular address that has nothing to do with volatile. For example, you might write a kernel and know that the firmware put some data structure with important info at a hard-coded address. So, this API certainly should not be tied to volatile in any way. Just like ownership/borrowing, APIs for convenient (and maybe even safe) volatile access can be built on top of this lower-level primitive. That's why I marked the previous posts about volatile as off-topic. |
|
I'll raise this at the next embedded WG meeting (tues 28th 20:00 CEST) to see if anyone else has thoughts.
I'd think so, we will often have a pointer to a large struct or array or quite possibly an entire memory region that is only for MMIO with fixed addresses (e.g. on Cortex-M, 0x4000_0000 through 0x5FFF_FFFF is all peripheral MMIO). |
And then would you want it to be UB to use that pointer outside the given range? Or what would the exact consequence be of setting a particular size? |
|
If it didn't take a size, would you assume a single word provenance or the whole memory, like an escaped pointer? I was imagining you'd want to be able to restrict it to the smallest usable provenance, which is generally known statically or easily bounded to a memory region. If there's not really any advantage to the compiler to knowing the possible valid range of the pointer, then I suppose just taking the address and giving it a whole-memory provenance is a simpler API. My guess for a typical embedded use-case is you'd create one of these pointers for each instance of a peripheral on your chip, so each has a non-overlapping size of say <100 words, and probably create them on-demand each time you accessed the peripheral. |
It would be allowed to access all memory that is outside of what the Abstract Machine knows about (
This means multiple calls to that function can overlap anyway, so a size does not give any disjointness guarantees. |
|
A size/span restriction does not seem useful. |
Right, I should have read the issue more carefully. I agree then, it doesn't seem like there'd be any benefit to giving a size, even if it is known. For naming, I'm also not entirely sure about saying |
|
Thinking a bit about the use cases here, just to make sure I understand:
You mention specifically "for these pointers created from hard-coded addresses", would the latter two runtime-y cases also follow/benefit from this API? If all three are relevant, I'd propose |
|
"external address" seems like a good term, |
|
Yeah I considered "extern", too -- but the term is awfully overloaded.
This is specifically to replace current uses of |
|
That makes sense for the third point! My second item is more for implementing an operating system, where you might want to map a page, zero it, then pass it on to "userspace". If you were implementing ASLR for example, you'd (more or less) be generating the base mapped address from an RNG, which would probably have come from some kind of integer rather than pointer. That being said, the OS itself probably sees the physical memory address the same as case one. Once the OS establishes the pointer, and passes it to userspace (where userspace is in case three), you're right that userspace doesn't have to re-establish provenance, I guess. |
|
"foreign" maybe? so there's "program memory" and "foreign memory". The function could be |
|
@jamesmunns from the kernel perspective this is memory outside of what Rust knows about, so if there are int2ptr casts there then using this function probably makes sense. However now that if you e.g. implement a global allocator, then the memory return by that is considered to be "known to Rust" and thus must not be accessed with that "external"/"foreign" provenance. |
But what if I want to perform |
|
inline asm provenance creation rules should be the same as FFI provenance creation rules (whatever those are). I don't know if that's fully decided yet, but in all other situations inline asm works "basically like FFI with a weird calling convention", and I see no reason to break from that convention. |
|
|
|
one other case to consider is where the program picks an address, and then memmaps to that address, using something like let addr: *mut u8 = 0x12340000 as *mut u8; // pick an arbitrary page-aligned address
let addr = mmap(addr as *mut c_void, 0x10000, PROT_READ | PROT_WRITE, MAP_FIXED | MAP_PRIVATE, fd, 0);imho |
That sounds pretty reasonable to me. |
|
In the embedded code I've encountered (STM32 mainly), this is the common pattern. unsafe {
// NOTE(unsafe) this reference will only be used for atomic writes with no side effects.
let rcc = &(*RCC::ptr());
// Enable clock.
$GPIOX::enable(rcc);
$GPIOX::reset(rcc);
}There will be an underlying crate that is mostly generated from the MCU vendor's SVD-files (often with some patch set with correction on top). The maps each MCU peripheral to a specific memory address impl GPIOA {
pub const PTR: *const gpioa::RegisterBlock = 0x4002_0000 as *const _;
pub const fn ptr() -> *const gpioa::RegisterBlock {
Self::PTR
}
}The pointer will be into some block, probably "Peripherals" below starting
For the proposed provenance API, are we saying that we will declare the entire Peripheral block on startup and then take additional offsets from inside that block for the individual pointers? Given the current embedded landscape, I believe that having an API to declare provenance for an individual pointer would be less of an upheaval than going via a block. (As an aside, I'm also not keen on the name |
|
Currently, when using EDIT: as one example: it would break all my tests in |
|
Personally I think "each calls returns a unique provenance of a given size" makes the most sense. It covers the most use cases with the least API surface area. Whole memory regions, splitting memory regions, "magical" allocators, etc. I'm not sure how useful it is to have "The One Unknowable Everything-Else Provenance" (i.e. no size parameter, single provenance for all "external"/non-rust addresses). Feels like that's only a very slightly smaller hammer than On that note, what about memory regions that can be relocated at runtime? Is this something that can be at all expressed under strict provenance (other than for discarding and re-creating the existing provenances)? I thought of |
|
Allocated objects in Rust cannot move. So such relocations (in general) have to be modeled like |
|
Supposing that this function did take a size, what would the semantics of a pointer created with size zero be? Would calling |
|
Doesn't Rust disallow memory allocations of size 0 (which is why Vec/Box/etc have special cases for ZSTs)? I would assume the same to apply here |
|
https://doc.rust-lang.org/nightly/std/alloc/trait.GlobalAlloc.html#safety-1 says it's UB to request allocations of size 0, which is different from creating an invalid pointer which is okay to be used for accesses of size 0 So my assumption is "Rust allocations cannot be zero-sized" would hold here? |
|
Heap allocations of size zero cannot be created with our global allocator. However, stack variables and global |
|
heap allocations of size zero can be created with some implementations of |
|
If only some native allocators support it then rust overall must assume it's not supported. |
yes, except that Rust can't declare that no zero-sized heap allocations are possible, they just can't be done with Rust's standard methods of allocating memory. |
I'm asking, because if so, it would make sense to implement |
|
ptr::invalid is a reasonable implementation for a zero-sized allocation (that cannot be freed).
|
|
Okay, after we spent most of the discussion above clarifying various misunderstandings -- how do we stand wrt adding an explicit operation here? Yes, we could tell people to use /// Converts an address to a pointer. The address must be referring to "external" memory, i.e. memory that is not
/// already part of a Rust allocated object.
///
/// Pointers derived from the result of this function may not be used to access any memory that Rust "knows about"
/// (such as `static`s including `extern static`s, stack variables, or heap allocations).
/// In other words, the returned pointer will have a [provenance] that indicates that it is specifically only allowed to
/// access "external", non-Rust memory.
/// It is okay to call this function multiple times for the same memory; it will return the same pointer each time.
///
/// You may derive references
/// from the result of this function, but note that these references come with the usual Rust aliasing requirements:
/// mutable references must be unique, and shared references must be read-only (except for bytes inside `UnsafeCell`).
/// This means that when multiple calls to `from_extern_addr_mut` are used to obtain pointers to the same memory,
/// and one of these pointers is used to create a reference, it is Undefined Behavior to use any of the other pointers
/// in a way that conflicts with the requirements of this reference.
/// Furthermore, note that Rust references allow spurious memory accesses, so it is a bad idea to create references
/// to MMIO memory regions.
///
/// # Example
///
/// Using `from_extern_addr_mut` to access an MMIO register that is known to reside at a particular
/// offset within an MMIO block at a fixed address:
///
/// ```no_run
/// const MMIO_ADDR: usize = 0xaffe_0000;
/// const REGISTER_OFFSET: usize = 0xfe;
///
/// let ptr: *mut u8 = std::ptr::from_extern_addr_mut(MMIO_ADDR);
/// ptr.add(REGISTER_OFFSET).write_volatile(0x01);
/// ```
fn from_extern_addr_mut<T>(addr: usize) -> *mut T { ... }I don't think we want this function to take a size, unless we are willing to say "any access outside that size is UB" -- which would make it harder for people to migrate from @rust-lang/opsem what do you think? |
|
@RalfJung What if the allocation will back the stack, heap, or other memory locations Rust does know about? Normal code will never need to do that, but operating system code (such as kernels and threading libraries) absolutely will. |
|
For first boot procedures on baremetal systems the answer is "you must do this in assembly, before entering Rust code". I suspect setting up a thread's stack and the global heap might have similar "don't let rust actually know you're doing it" rules. |
|
@DemiMarie that memory needs to go through some sort of "phase transition", similar to memory returned by the global allocator, where it is removed from the "external memory allocation" it was in and instead becomes part of a newly born native Rust allocated object. That is beyond the scope of this issue. To me, the main thing I was unsure about in these docs is whether we want to describe this function as "create a new allocated object from outside-Rust memory", or "give access to some outside-Rust memory". The former would imply that you can only call this function once for each memory range, which seems too limiting. But at some point a Rust allocated object is logically being created, and I feel it would be good to talk about that -- I am just not sure how, since that action is entirely axiomatic, i.e. we never actually tell the compiler about it, we just "imagine" that such objects exist and then they appear (assuming there is actually accessible memory there and they are disjoint from stack/heap/statics). |
|
Well if (1) this really is for MMIO and so (2) the target is only accessed with volatile, then do we need to consider it a standard rust allocated object at all? Within the llvm lang ref it's stated that a volatile access of an address isn't used as evidence that a normal access of the address is also allowed. Do we want to try and accept a logic of this sort into rust? |
|
I don't think it's just MMIO. It's also relevant for cases where particular things are stored at particular addresses, e.g. the interrupt vector or other kinds of communication with the firmware in a freestanding environment. Not sure if some OSes don't also put particular information (such as the environment or args block) at particular addresses. |
|
I feel like magic addresses for communicating with firmware are spiritually MMIO, even if they're actually stored in normal memory. The edge case is probably something like the memory address |
One doesn't use I would prefer to use MMIO only for memory that needs |
|
Addresses that are used for communication with the firmware may need volatile if the firmware accesses them from asynchronous smm interrupts, right? |
I mean, I do. Rust eliding a subsequent access is probably fine when it's |
That sounds more like a usecase for atomics and atomic_signal_fence / compiler_fence to me? |
|
There also has a corner case, what if MMIO has a fixed address
This still falls into UB domain |
you'd probably have to rely on inline assembly for that then. |
|
Yeah, asm doesn't have a specific restriction against using 0 as an address like Rust does. Bonus: you know that it's outside of Rust's address space and can't interfere with Rust. Aside: extremely silly that they zero initialize the pointer that way in the docs. |
|
Accessing address |
Now that the `exposed_provenance` and `strict_provenance` features have been stabilized, but `with_exposed_provenance_mut()` isn’t const, and `without_provenance_mut()` is UB to dereference. `core::ptr`’s documentation says: > Situations where a valid pointer must be created from just an address, > such as baremetal code accessing a memory-mapped interface at a fixed > address, are an open question on how to support. These situations will > still be allowed, but we might require some kind of “I know what I’m > doing” annotation to explain the situation to the compiler. It’s also > possible they need no special attention at all, because they’re > generally accessing memory outside the scope of “the abstract machine”, > or already using “I know what I’m doing” annotations like “volatile”. See rust-lang/rust#98593 for more information about future development around converting MMIO addresses to pointers.
and others
This issue is part of the Strict Provenance Experiment - #95228
On some platforms it makes sense to just take a hard-coded address, cast it to a pointer, and starting working with that pointer -- because there are external environment assumptions that say that certain things are provided at certain addresses.
This is perfectly fine for Rust as long as that memory is entirely disjoint from all the memory that Rust understands (
staticglobals, stack allocations, heap allocations). Basically we can think of there being a single hard-coded provenance for "all the memory that is disjoint from the Abstract Machine", and that is the provenance we would like to use for these pointers created from hard-coded addresses. These restrictions make this operation a lot easier to specify thanfrom_exposed_addr. (Remember:from_exposed_addris outside of Strict Provenance. The goal of this issue is to provide a way to write such code while following Strict Provenance.)In the spirit of the Strict Provenance APIs, that means we probably want a function that does this, and that we can attach suitable documentation to. There are some open questions for the syntax and semantics of that function:
make_alloc,assume_alloc,hard_coded_alloc? I am leaning towards something with "alloc" because this function is basically like an allocator, except that you tell it at which address to allocate and you have to promise that that is Okay To Do.usizefor the address and return*mut T. Should it also take a size, saying how large this assumed allocation is?Cc @Lokathor who keeps mentioning this usecase every time I want to ban int2ptr casts. ;)
Tagging WG-embedded since that's where this kind of stuff mostly happens (AFAIK)
The text was updated successfully, but these errors were encountered: