4 ms·
Reentrancy bugs like this one are surprisingly common. Having reviewed lots of unsafe Rust code, unnoticed calls into outside code (that can then reenter your o
by LegionMammal978 1y ago
Reentrancy bugs like this one are surprisingly common. Having reviewed lots of unsafe Rust code, unnoticed calls into outside code (that can then reenter your own code or modify your data structures, blowing everything up) is one of the most common soundness issues I've found across different projects.
The main solutions seem to be either restricting how possibly-invalidated data can be held (e.g., safe references in Rust), or having some coloring scheme (e.g., "pure" annotations) to ensure that the functions you call are unable to affect your data. Immutable languages can mitigate it somewhat, but only if you have the discipline to maintain a single source of truth for everything, and avoid operating on stale copies.
- ramon156 1y agothe solution? #[deny(unsafe_code)]
- Ygg2 1y agoEh. It will work with your code but at some point your dependencies will have to dive into unsafe (e.g. calling C libs/kernel, SIMD, ASM by hand, etc.). Minimize unsafe, auditing libs with Geiger, and minimizing outside dependencies to a few reliable vendors, is what is practically needed.
- deleted 1y ago[deleted]
- VWWHFSfQ 1y agoAny reasonably sophisticated web browser is going to require a decent amount of unsafe {} if only just for performance reasons. Obviously would be much easier to audit though.