3 ms·

This does assume that all `unsafe` usages are wrapped in correctly `safe` guards though, doesn't it? You can wrap `unsafe` functionality without checking and t

This does assume that all `unsafe` usages are wrapped in correctly `safe` guards though, doesn't it? You can wrap `unsafe` functionality without checking and thus have memory issues, or if the unsafe wrapper hasn't correctly validated all possible entries that can cause memory corruption. Then any consumer of this dependency has a possible security issue with the right inputs to the consumer, which can trigger passing an exploit down to the unsafe portion.

tialaramex 5y ago
Yes. If your safe code blows up but everything else seems fine, the fault is one of (starting with least likely): * Your hardware is broken. Did you spill the entire glass of wine on that laptop? * The Rust compiler has a bug. Or, equivalently, LLVM has a bug and rustc depended on LLVM to be correct. Or, your OS kernel has a bug. These are all unlikely, but they do happen. * A safe wrapper in a popular library you depend on is not fulfilling its contract and you noticed before anybody else. * A safe wrapper in your code, or in some lesser known crate you depend on, is not fulfilling its contract. If you just fired Jim for writing LGTM without reading his code reviews, start with any code Jim reviewed that has "unsafe" in it. Notice that the blame definitely is not on the safe code which relied on a guarantee that wasn't fufilled. This is a human construct layered on top of what Rust's compiler is actually delivering, but it's still important to think this way. If in hindsight the function Jim didn't review correctly should be marked unsafe because you need to check your parameter wasn't zero when calling it, do exactly that, never write... // Marked safe, but actually not safe to call with zero ... in the comments for the function, you're making your own life harder.
- kibwen 5y ago
  > Or, your OS kernel has a bug. These are all unlikely, but they do happen. For fun, here's an example of the Rust stdlib itself working around such things: https://github.com/rust-lang/rust/blob/74ef0c3e404cc72c08b2d1e14506f90d9e877269/library/std/src/time.rs#L223-L247 https://github.com/rust-lang/rust/blob/74ef0c3e404cc72c08b2d...

tialaramex 5y ago

Yes. If your safe code blows up but everything else seems fine, the fault is one of (starting with least likely): * Your hardware is broken. Did you spill the entire glass of wine on that laptop? * The Rust compiler has a bug. Or, equivalently, LLVM has a bug and rustc depended on LLVM to be correct. Or, your OS kernel has a bug. These are all unlikely, but they do happen. * A safe wrapper in a popular library you depend on is not fulfilling its contract and you noticed before anybody else. * A safe wrapper in your code, or in some lesser known crate you depend on, is not fulfilling its contract. If you just fired Jim for writing LGTM without reading his code reviews, start with any code Jim reviewed that has "unsafe" in it. Notice that the blame definitely is not on the safe code which relied on a guarantee that wasn't fufilled. This is a human construct layered on top of what Rust's compiler is actually delivering, but it's still important to think this way. If in hindsight the function Jim didn't review correctly should be marked unsafe because you need to check your parameter wasn't zero when calling it, do exactly that, never write... // Marked safe, but actually not safe to call with zero ... in the comments for the function, you're making your own life harder.

kibwen 5y ago
> Or, your OS kernel has a bug. These are all unlikely, but they do happen. For fun, here's an example of the Rust stdlib itself working around such things: https://github.com/rust-lang/rust/blob/74ef0c3e404cc72c08b2d1e14506f90d9e877269/library/std/src/time.rs#L223-L247 https://github.com/rust-lang/rust/blob/74ef0c3e404cc72c08b2d...