`DataMember::read` is unsound about rs-process-memory HOT 3 CLOSED

Hi there, thanks for reporting this.

First of all, this crate is maintained, but I consider it pretty much feature complete.
Of the other two open bugs, one has turned into a feature request from a misunderstanding of the API (which is partially handled by other crates and the PRs for them seem to have fallen by the wayside) and the other I have been unable to reproduce myself and so can't do anything with for now. I'm also looking into how the eventual move to strict provenance for pointers may affect this crate, but don't have any immediate plans for changes.

With regards to the issue of soundness - I think this is intractable and have no idea how to solve it. If you have any suggestions, then I would welcome them and be happy to implement them.
The main issue here stems from the fact that we do not control the memory from which we are reading from, and thus - as far as I am aware - there is no way before reading the pointer that we can guarantee that the memory referred to is indeed a valid T.
With that in mind, would be best way to solve this be to either (non-exclusively):

• Flag the potential unsoundness for library consumers to have to deal with in documentation?
• Mark the function as unsafe? This again pushes the contract for safety to library consumers
• Some other option that I haven't thought about?

Thanks again for the report.

from rs-process-memory.

I am also unsure how the issue would best be fixed but I've been thinking of some ideas. At a minimum I think the function should be marked unsafe with the problem clearly laid out.

The only way that I can think of to truly fix this is to somehow inspect the buffer after copying the memory to make sure it contains a valid bit-pattern. I think this would probably require a trait to be added for this and implemented for the various types. Unfortunately this would probably be pretty messy. Due to coherence rules user's wouldn't be able to implement the trait for any types they don't own which could be a problem if the type you're interested in comes from a third crate.

I can provide some mockups later today and will continue thinking about the issue for a better preposal.

from rs-process-memory.

One solution might be to use bytemuck to provide the traits and then use CheckedBitPattern as a trait bound for the read operation. Bytemuck can also handle the casting part as well. Only potetial downside I see to this (other than adding a dependency) is that it enforces Rust's requirements for reading a bool, which is good to avoid an invalid cast, but might not be what you want when reading an arbitrary external process's memory. This could be worked around though with some sort of inbetween type T that implements From<T> for bool though that treats all non-zero values as true.

from rs-process-memory.