Handling of explicit memory addresses

[coastalwhite]

TLDR: It would be useful for OS and embedded it there was a way to handle reading / writing to specific memory addresses.

Heya, I tried to see if something like this was already suggested, but I could not find a similar feature request. I would also fully understand if people think this is out of scope for Miri.

In several contexts, mostly embedded and OS development, you will read and write to specific memory addresses to control peripherals. It would be awesome if Miri could somehow handle these situations. The simplest and most flexible method I can think of is being about to register a handler through an FFI interface that is given the address and optionally the value that is being written. Then, when an invalid address is read or written to, all the handlers are enumerated and called. When a handler is succeeds or explicitly fails, that handler is used as the result for read/write.

There is probably a better solution that I am not seeing. If this use case is worth considering for Miri, then I propose a bit of time is spent on what solution would be ideal.

Thank you in advance.

[RalfJung]

Indeed, I think it would be great if Miri could support this. :) Some sort of callback for volatile memory accesses is exactly what I had in mind. I could easily make this a student project; all I am missing is one or more concrete, ideally fairly small and self-contained, case studies I could give to the student as the goal for the project, and ideally someone to talk to if we have any questions. Unfortunately I know next to nothing about real-world MMIO-based drivers, so it is hard for me to supervise such a project entirely on my own. Alternatively I could mentor this as an open source contribution, if someone motivated and interested shows up.

[coastalwhite]

I had this idea while writing a memory-mapped UART driver for an embedded device. I, personally, think that would be a good target, as it would make the behavior of the callback clear. Namely, it could write out to STDOUT.

If I understand correctly, while filling in some of the blanks here. The idea is to utilize the existing "-Zmiri-native-lib=<path/to/lib.so>" interface. If the specified shared library contains a certain symbol name (e.g. _miri_volatile_handler) that will get added to a list of handlers. When a volatile memory access occurs, this list of handlers will get enumerated, and the result of the first callback that either explicitly handled the memory access or explicitly errored on the memory access will get used.

[saethlin]

The idea is to utilize the existing "-Zmiri-native-lib=<path/to/lib.so>" interface.

I would not recommend that. There are existing Miri magic functions that you can call, such as miri_print_borrow_state which are hooked by the interpreter in the same way that shims are. What I'd imagine is you call another such magic function to add your handler (also implemented in Rust). It would be much better to avoid needing the native-lib mechanism.

[RalfJung]

Yeah I did not mean to suggest anything related to "native-lib". :)

[coastalwhite]

Ah, I had read about native-lib recently and guess I just filled gaps in the wrong way. That makes a lot of sense. So something like the extern functions declared in https://github.com/rust-lang/miri/blob/master/tests/utils/miri_extern.rs?

[RalfJung]

Yeah -- though this one here is a lot more complicated since in the end it's about Miri calling into user code, rather than the other way around.