> All unsafe does is mean you’re only allowed to call unsafe functions from unsafe blocks or unsafe functions.
That's the mechanism by which the safety invariant is enforced, not a description of the safety invariant itself; it's the "how", not the "why". The safety invariant itself can be roughly summarized as "memory corruption can't originate in safe code".
I think the Ferrocene people are working on a more formal definition of memory safety in Rust that excludes things like this, since of course no program can defend itself against it.
There are some cases, especially when embedding other runtimes with different invariants, where Rust's safety model isn't quite expressive enough and so people are forced to provide unsound APIs for the sake of practicality. https://docs.rs/pyo3/latest/pyo3/marker/index.html#drawbacks is an example. None of those have been cited here, though, and it's not clear to me that firmware inherently imposes this kind of challenge; as far as I can tell, it's perfectly possible to write sound Rust APIs for firmware.
That's the mechanism by which the safety invariant is enforced, not a description of the safety invariant itself; it's the "how", not the "why". The safety invariant itself can be roughly summarized as "memory corruption can't originate in safe code".
> retrieving the raw fd from a BorrowFd is unsafe
No it isn't. https://doc.rust-lang.org/std/os/fd/struct.BorrowedFd.html#m...
> opening /proc/mem as a file
I think the Ferrocene people are working on a more formal definition of memory safety in Rust that excludes things like this, since of course no program can defend itself against it.
There are some cases, especially when embedding other runtimes with different invariants, where Rust's safety model isn't quite expressive enough and so people are forced to provide unsound APIs for the sake of practicality. https://docs.rs/pyo3/latest/pyo3/marker/index.html#drawbacks is an example. None of those have been cited here, though, and it's not clear to me that firmware inherently imposes this kind of challenge; as far as I can tell, it's perfectly possible to write sound Rust APIs for firmware.