search

uazu / qcell

Statically-checked alternatives to RefCell and RwLock
Apache License 2.0
349 stars 22 forks source link

Be aware of pointer provenance #33

Open geeklint opened 2 years ago

geeklint commented 2 years ago

There are new APIs proposed in 95228 which may eventually lead to the deprecation of ptr as usize casts.

qcell uses these casts in many places, namely in functions -> QCellOwnerId, as well as to check the uniqueness of cells in rw2/rw3 calls.

Since they're only used for comparisons, I don't think qcell really needs to worry about retaining provenance information (i.e. the change would be to replace ptr as usize with ptr.addr()).

I figured I'd open this issue to keep an eye on strict_provenance and prepare to update qcell if/when those APIs become stable.

geeklint commented 2 years ago

I notice there's a someday-maybe label, that would probably be appropriate here.

uazu commented 2 years ago

I've been following the provenance articles. I think it doesn't affect how we use addresses in this crate, because we just extract an integer, and it is never converted back to a pointer. The only way this could affect safety is if we get the same integer ID from two different pointers. As far as I can see, this could only happen if two different allocations come from different address spaces (for processors that have independent address spaces, e.g. different address spaces for code, data and I/O, i.e. the same address could have a different meaning depending on whether it is used for a jump, a data fetch, or an I/O operation). I still can't see how we could get a collision, because all our pointers should be into the data address space. But this is perhaps something to watch out for if some very unusual processor gets Rust support. (The provenance changes would allow a weird processor like that to be supported.)

Paging overlays into a limited address space might also cause issues, e.g. the PDP series of minicomputers (or even ZX Spectrum 128) used to allow user code to page different memory into the same address range, to allow a processor with a limited address size to access more memory. But this would add a whole load of other complications for a language like Rust besides the issues for qcell. Something to watch out for, in any case.

fd commented 2 years ago

But this is perhaps something to watch out for if some very unusual processor gets Rust support. (The provenance changes would allow a weird processor like that to be supported.)

WebAssembly modules with multiple memories, if/when stabilized, is one such a platform. Different memories are addressed by indexes, so addresses could conflict. Obviously, Rust support for this feature is nonexistent atm.