5 ms·
If we are talking of domains where memory safety is an issue, then surely the category of memory safety must include OOM-safety? i.e. Safe handling of out-of-me
by jorangreef 6y ago
If we are talking of domains where memory safety is an issue, then surely the category of memory safety must include OOM-safety? i.e. Safe handling of out-of-memory conditions under overload?
- saagarjha 6y agoSure, but crashing cleanly in out-of-memory conditions is generally regard to be "safe" (if undesirable for reliability).
- jorangreef 6y agoI personally like panics and assertions, but the "safety" of the approach would still have to depend on the characteristics of the system. I do not agree that panic-on-OOM should be considered "safe" at a global level hidden within a std lib, where there is no knowledge of the target domain. For example, if an attacker could arbitrarily inject overload to restart rate-limiting processes and then abuse this to trivially brute-force OTP logins. The definition of safety with respect to a resource in general always needs to include the safety of the system as it crosses the threshold i.e. in this case into out-of-memory, so if a system claims memory safety, the first thing I would want to ask is, what about OOMs?
- yellowapple 6y agoIs it? I'd say "crashing cleanly" is oxymoronic; "crashing" strongly implies a failure of the process to clean up after itself after doing so. Any sort of crash can wreak havoc on whatever non-atomic operations were in-flight.
- littlestymaar 6y agoLots of things that must be memory-safe are run on top of the Linux kernel, which doesn't give you the OOM-safety you're looking for because of overcommit+OOM killer. Anyway, for Windows and other plateform where this is a reasonable goal, there is work in progress to add this to Rust. See this RFC[1] which has been merged and whose implementation progress can be followed here [2] [1] https://github.com/rust-lang/rfcs/pull/2116 https://github.com/rust-lang/rfcs/pull/2116 [2] https://github.com/rust-lang/rust/issues/48043 https://github.com/rust-lang/rust/issues/48043
- jorangreef 6y agoLots of things are done that way but there is also plenty of software for which OOM safety is a critical component of memory safety. As you say, not every platform is Linux, and if Rust will be moving towards OOM safety as a global default and making this explicit throughout the std lib, then I think we are both in agreement.
- yellowapple 6y agoWhich, relevantly, is something where Zig excels. OOM is just another ordinary error to be handled, and indeed is an error that can be leveraged on a much more fine-grained basis than an OS-level allocation. Being able to gracefully handle OOM conditions is a dramatic improvement over the average C codebase; enforcing that graceful handling, as Zig does by requiring callers to handle errors as part of the return type and by including allocation failures in that category, is a godsend. And taking this further, since Zig's convention around allocators is for them to be an explicit argument of all functions needing to allocate, it's trivial to write tests specifically to validate correct behavior in OOM conditions. There's even a custom allocator in the standard library for exactly this purpose.
- jorangreef 6y agoYes, and I think the matrix should really include these aspects of Zig's safety to be a fair comparison, because otherwise it's like evaluating Rust's safety but without mentioning the borrow checker.