Owned `VolatileCell` type?

[phil-opp]

Some people expressed interest in a volatile Cell-like type that owns the value, similar to the v0.3 interface of this crate. I think that such a type would be a nice addition to the pointer types proposed in #29, but the question is whether it is possible to implement such a type in a sound way.

The fundamental issue is that references are marked as dereferenceable by the compiler, which permits LLVM to insert spurious reads. This is not valid for volatile values since they might change in between reads. This issue was e.g. discussed in this thread on the Rust internals forum in 2019, with the conclusion that such a type would require special language support.

About half a year ago, rust-lang/rust#98017 was merged, which (if I understand it correctly) removed the dereferenceable annotation from &T where T contains an UnsafeCell. Maybe this change makes it possible to safely implement a VolatileCell with an inner UnsafeCell now?

[phil-opp]

I started to prototype a possible implementation in https://github.com/rust-osdev/volatile/blob/volatile-cell/src/cell.rs (based on #29). It looks like there is indeed no dereferenceable attribute emitted for VolatileCell read on recent compiler versions:

; volatile::cell::VolatileCell<T,A>::read
; Function Attrs: mustprogress nofree noinline nounwind nonlazybind willreturn uwtable
define internal fastcc i32 @"_ZN8volatile4cell25VolatileCell$LT$T$C$A$GT$4read17hb9d32dab412340c7E"(ptr noundef nonnull align 4 %self) unnamed_addr #6 {
start:
  %0 = load volatile i32, ptr %self, align 4, !noalias !176
  ret i32 %0
}

In comparison, I built with Rust 1.61, which does not contain rust-lang/rust#98017. We see that the dereferenceable attribute is set for the %self parameter:

; volatile::cell::VolatileCell<T,A>::read
; Function Attrs: mustprogress nofree noinline nounwind nonlazybind uwtable willreturn
define internal fastcc i32 @"_ZN8volatile4cell25VolatileCell$LT$T$C$A$GT$4read17haea1052646ef9bf4E"(i32* noundef align 4 dereferenceable(4) %self) unnamed_addr #6 {
start:
  %0 = load volatile i32, i32* %self, align 4
  ret i32 %0
}

So this looks promising. However, I'm not sure if this is something that we can rely on. Is this behavior guaranteed by the language now?

---

The above result was acquired using cargo +1.61 rustc --tests --release -- --emit=llvm-ir. This places a *.ll file under target/release/deps. To ensure that VolatileCell::read is not inlined, I marked it as #[inline(never)].

[phil-opp]

Unfortunately, the dereferenceable attribute is still emitted for methods that take &mut self, e.g. VolatileCell::write. We could take &self in these methods as a fix, but this would force us to remove the Send implementation.

Alternatively, we might be able to exploit rust-lang/rust#106180 once it's merged. As I understand it, adding a PhantomPinned field to the VolatileCell type should remove the dereferenceable attribute then. Of course, the question is again whether we can rely on this behavior.

[phil-opp]

cc @RalfJung @Lokathor @kevinaboos

[Lokathor]

I kinda fundamentally don't get what you're going for here. The whole point of MMIO being separate types is that it's not normal memory. And one of the things about it not being normal memory is that you don't ever actually have exclusive ownership of the memory. In addition to however the rust code decides to divide up the task of accessing that address, there's also the hardware that's always also at least looking at that address, and possibly modifying what's at that address. You are permanently sharing an address with an additional party, since before your program begins.

[repnop]

Unfortunately, the dereferenceable attribute is still emitted for methods that take &mut self, e.g. VolatileCell::write. We could take &self in these methods as a fix, but this would force us to remove the Send implementation.

It is my understanding that &mut should pretty much never be involved with a VolatileCell abstraction, as it makes too many guarantees about the state of the underlying data (mainly, asserting that the data will not change outside of that unique reference). Shared references should always be used with UnsafeCell to assert mutation can occur from behind the compiler's back, but as Ralf points out in this older Zulip thread, removing dereferenceable from shared mutable references is still not enough to guarantee this abstraction is sound, and at least the consensus seemed to me at the time that a proper lang item for a VolatileCell type would be the basis for any further abstractions like this as it would be known to the compiler. I'm not aware of any movement on that front currently, however.

[phil-opp]

I kinda fundamentally don't get what you're going for here.

The main motivation for an "owned" type like this that you can abstract the MMIO memory using normal repr(C) Rust structs. The only difference would be that the leaf fields are wrapped inside VolatileCell. This way, no macros are needed and you also don't need to do any address calculations yourself.

In addition to however the rust code decides to divide up the task of accessing that address, there's also the hardware that's always also at least looking at that address, and possibly modifying what's at that address. You are permanently sharing an address with an additional party, since before your program begins.

I'm awary of that. The &mut self parameter is just for ensuring no concurrent access from the software side. We deal with the hardware side by restricting the interface of VolatileCell. For example, there is no way to get a reference to the wrapped value and the only available methods map to volatile operations.

[phil-opp]

@repnop Thanks a lot for the info!

It is my understanding that &mut should pretty much never be involved with a VolatileCell abstraction, as it makes too many guarantees about the state of the underlying data (mainly, asserting that the data will not change outside of that unique reference).

That's what I feared.. There is no way to restrict an inner field to a shared reference, right? I mean something like Rc<T>, but without needing an inner pointer.

but as Ralf points out in this older Zulip thread, removing dereferenceable from shared mutable references is still not enough to guarantee this abstraction is sound

Thanks, I was not aware of that Zulip thread. From the thread:

[RalfJ] as I said further up this thread, the proposed change in rust-lang/rust#98017 does not help with VolatileCell, for the reasons stated by Connor Horman

I assume this refers to this comment above?

With the change to UnsafeCell to disable dereferencable (to allow self deallocation, approximating dereferencable_on_entry), would this make a lib volcel not problematic at the LLVM level?

note that UnsafeCell is still dereferenceable-on-entry. LLVM just doesnt have a flag for that (yet).
so, no luck yet for VolatileCell, sorry. :/ one problem at a time.

I'm now sure if I understand this correctly, but I assume that the issue is the &self argument in the UnsafeCell::get method, which is still marked as dereferenceable? If so, couldn't we work around that by using the pointer-based UnsafeCell::raw_get method instead? Or is the issue somewhere else?

[Freax13]

Not sure if this is something, but just wanted to mention the idea:
Instead of creating references to T, create references to zero sized types. This bypasses the whole dereferencable problem by reducing the amount of bytes that LLVM could dereference to 0. This might cause problems with provenance though.

[Freax13]

Is the only problem with dereferencable that it can cause spurious reads? If so, that might not necessarily be a problem for MMIO regions where reads don't have side-effects (e.g. prefetchable PCI bars).

[Lokathor]

The main motivation for an "owned" type like this that you can abstract the MMIO memory using normal repr(C) Rust structs. The only difference would be that the leaf fields are wrapped inside VolatileCell. This way, no macros are needed and you also don't need to do any address calculations yourself.

I just don't think Rust as it is today can handle this. Until there's an actual language level change I wouldn't ever suggest anyone try to do that.

I realize that this is probably "easy" for me to say because I only program for a single embedded device and not a whole ecosystem of stuff, but for the GBA I never use volatile with types that can't be read/written in a single instruction (1, 2, or 4 bytes). It's just ints or newtyped ints all the way through.

If you absolutely need it to look struct-like based on the usual struct definition syntax, I'd suggest a proc-macro that accepts a C struct as the input but expands to a newtype over usize (holding the base address) and with methods for the address of each "field" of the region (each method offsets by a const that the proc-macro has computed).

If you want a VolatileCell wrapper that would need an RFC so it can get proper compiler support.

[phil-opp]

I just don't think Rust as it is today can handle this.

Probably, but I still would like to understand what's the actual issue. Is there a potential codegen issue that could still lead to a dereferenceable attribute or is the only concern that we rely on unspecified compiler behavior?

Until there's an actual language level change I wouldn't ever suggest anyone try to do that.

I fully agree that a pointer-based approach is the better and safer solution for now. However, the cell-like approach is still quite popular in the ecosystem, e.g. through the vcell crate. So if there was a way to make such an interface safe with the current compiler versions, we could make several projects safer without requiring them to completely rewrite their volatile code.

[phil-opp]

@Freax13

Instead of creating references to T, create references to zero sized types. This bypasses the whole dereferencable problem by reducing the amount of bytes that LLVM could dereference to 0. This might cause problems with provenance though.

This would basically be the pointer-based approach, right? We could not create a struct with e.g. three volatile u16 fields this way.

Is the only problem with dereferencable that it can cause spurious reads? If so, that might not necessarily be a problem for MMIO regions where reads don't have side-effects (e.g. prefetchable PCI bars).

I guess it could still be an issue if values change between (spurious) reads and LLVM does not expect that?

[Freax13]

Instead of creating references to T, create references to zero sized types. This bypasses the whole dereferencable problem by reducing the amount of bytes that LLVM could dereference to 0. This might cause problems with provenance though.

This would basically be the pointer-based approach, right? We could not create a struct with e.g. three volatile u16 fields this way.

We could use a macro to create another struct. The struct would have fields with the same names as the original, except all types would be switched out for zero sized types. That way the whole struct would still be zero sized, but I'd still be possible to access the fields like normal fields.

[phil-opp]

Ah, but then we would need to store the field offsets somewhere. So we could get something similar to @Lokathor's proposal above:

If you absolutely need it to look struct-like based on the usual struct definition syntax, I'd suggest a proc-macro that accepts a C struct as the input but expands to a newtype over usize (holding the base address) and with methods for the address of each "field" of the region (each method offsets by a const that the proc-macro has computed).

[Freax13]

Ah, but then we would need to store the field offsets somewhere.

The offset could be part of the zero sized type for each field e.g. with const generics. I'm currently drafting something up, will publish later today.

So we could get something similar to @Lokathor's proposal above:

If you absolutely need it to look struct-like based on the usual struct definition syntax, I'd suggest a proc-macro that accepts a C struct as the input but expands to a newtype over usize (holding the base address) and with methods for the address of each "field" of the region (each method offsets by a const that the proc-macro has computed).

Using methods has the limitation that splitting a reference to struct into references to fields is not possible.