Allow mapping memory safely using `volatile` crate?

[danburkert]

Allow mapping memory safely using `volatile` crate?

[burdges]

It's unclear if [Volatile<u8>] would ever addresses the concerns but if so that's highly file format specific and not generally applicable.

There are various techniques for doing this correctly, like checksums at either the record or file level, doing a volatile comparison after reading or writing, using record-width block ciphers, worrying about syncs, and simply treating the data as unstable throughout the code. Almost all involve reading and writing whole records which makes anything u8 incorrect, except as a basic building block.

[goose121]

I agree that reading and writing entire records would still require further mechanisms to ensure integrity, but using [Volatile<u8>] means that the data changing while you have a reference to it does not cause undefined behaviour, allowing the data to be accessed safely. Any transformation from a subslice of the [Volatile<u8>] into a different type where the data having changed partway through reading the subslice could cause UB would require the client to write or invoke further unsafe code, in which case either the client or that unsafe code would be responsible for ensuring that the data was valid.

Furthermore, they couldn't do something like turning it from a [u8] into a string slice via a safe method, and then having the data change while the string slice referred to it, because the data would have to be copied out of the Volatile wrapper when it was read into a [u8], at which point changes to the mapped data would have no effect on the string slice created

[burdges]

There is a consensus against volatile with remaining options being &[AtomicU8] with relaxed ordering, or maybe *mut u8, &[UnsafeCell<u8>], &[Cell<u8>], or an opaque type with buffer copy methods. Quotes:

"That said, I cannot think of any reason to actually use volatile here, or even think of any case where adding volatile removes UB. Adding volatile helps control the exact accesses that hit the memory subsystem, but I do not think it is ever needed from a UB perspective. So, to the best of my knowledge, &[AtomicU8] (and making every single access Relaxed) is okay. It is also rather horrible to use, I assume."

"relaxed atomic load/stores are the same as regular load/stores at an assembly level .. [and more optimizable] compared to volatile load/stores"

Relaxed &[AtomicU8] gives us fence which prevents the compiler or CPU from optimizing away simple protections like double accesses. In fact checksums, or MAC tags, work without atomics, and provide stronger assurances, but many applications do not require such strong assurances.

[boomshroom]

I'm looking at code for a userspace device driver that mmaps in a device file and writes to it. The reason volatile is needed is because the compiler can't see that the writes are actually being read somewhere. That's the whole reason volatile exists: to allow optimised programs to use memory-mapped I/O. My first encounter with Volatile was writing to the x86 frame buffer. It's not thread safety that's needed (probably), but simply to ability to prevent writes from being erased.