Gregory's Server@marcan @koteisaev The argument that a memory safe language would have prevented the problem is incorrect, because terminating the program (kernel) on invalid operation *is* something that could also happen in a memory safe language and seems even the default in Rust for many things. Whether you could have done it differently (certainly!) and whether Rust makes this easier or not is a different discussion.
|
18 comments
 @marcan I agree that memory-safe languages are necessary. And many others here would agree on this. @koteisaev @marcan My point is that memory safety does not help here. Because a panic at a out-of-bounds is memory safe and would still have the exact same effect. Hector's argument seems to be that other things you can optionally do in Rust would potentially allow to avoid this, but this is not the result of using a memory safe language per se. I agree about the sad state of software engineering and I also I agree about the advantages of memory safety in general. @marcan @koteisaev I can almost agree with this, but my conclusion from this is not "let's dump C because it is fundamental impossible to write good software in C and move to Rust which fixes everything", but there are some good ideas in Rust which help write better software but there is also continuously improved tooling for C one can use, so we can also gradually improve this.  @koteisaev Broken input data that caused a NULL pointer dereference. Which is a memory safety problem. NULL pointer dereferences are impossible in safe Rust code. (Also memory leaks are *not* a memory safety problem and are possible in safe Rust; this is a common misconception about what "memory safety" means.) @marcan Null deref? @marcan Still, this is NOT enough to prevent failure in situation when "user input" is involved, even if it is some "content update" for security driver. @koteisaev Yes it is. Again, you can statically forbid panic, and (safe) Rust already forbids unsafe memory accesses. Therefore, it is impossible to (memory error) BSOD regardless of how you handle user input in the general case. The language forces you to handle the bad input gracefully somehow (typically by returning and propagating an error). About the worst you can do is infinite loop (but no language can protect against that because it equates to solving the halting problem). @marcan "w (typically by returning and propagating an error)." Propagating to the exit of process with an error code. Here we are again at need for some standard of how to deal with faulty drivers in general, such as "reboot with replacement by error reporting code that will send error dump somewhere", "isolate drivers in some container-like environment that would NOT cause complete boot BSOD, unless special cases like filesystem driver" (but then such EDR impossible per se), at os level... @marcan If it was always so, then nobody would ever see THAT bsod, as it was caused by crashing kernel driver, a very privileged software. So it means that for windows at least it is not ended up with some standard protocol with 'exclamation on a software device". @marcan Sounds as argument against big kernel and in favor more isolated drivers, and against "hyper-privileged" software in general... @marcan Thanks for detailed explanations. Now it seems I better understand some things. @marcan @koteisaev . My preferred solution is to use a subset of C and compile to eBPF which is then verified at run-time. |
@uecker @koteisaev The argument is that using a memory safe language would be a *requirement* to be *able* to avoid this class of problems, as evidenced by decades of memory safety bugs. Yes you can write crap code in any language, but it's plainly obvious to everyone who isn't in denial about the state of software engineering that approximately nobody can write correct and memory-safe complex code in memory-unsafe languages.