|
Top-level
 @koteisaev A memory-safe language would force you to make an active choice to crash, which at least gives you a chance to, you know, not do that and instead just bypass the update or fail gracefully. Yes, it is still possible to write crap code for memory-safe languages, but you generally have to do that much more on purpose. With a memory-unsafe language you just don't think about it and the default option is to crash (or worse). 26 comments
 @uecker@mastodon.social @marcan@social.treehouse.systems @koteisaev@mastodon.online The programmer has to make sure the code does not panic by default in the kernel. @uecker @koteisaev It is trivial to set up a Rust build to make panic a compile time error, forcing you to use primitives that don't do that and to handle the errors gracefully, such as `.get()` instead of indexing with []. You cannot do that in a memory unsafe language, fundamentally. @marcan @koteisaev You can not do what? Forcing people to use at instead of [] in C++? Would certainly be possible. But the discussion what "you could do" misses the point completely. What would happen in reality in a poor code base written on limited budget? Most likely would simply panic, or? @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. @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.  @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. @marcan Here broken piece of input comes, and your memory safe code dies with exit code 9000. I mean, this whole situaiton when faulty driver can cause crash whole system instead of markng this driver as faulty and to not not use it at next boot, and if necessary, reboot with new settings, or use special fallback driver whose purpose would be to report about problem on next reboot, and then it would be quite short outage and systems would be alive after few reboots, read - few minutes max. @marcan @koteisaev even panicking would be better than null pointer deref, panics clearly point at the offending driver, and the os can use that information to reboot with the driver blacklisted (or increment a failure counter, or whatever else policy would be appropriate)
|
Gregory's Server
@marcan @koteisaev Wouldn't you get a panic by default for an out-of-bounds access in Rust? How would the end result be different? Also see Ariane 5 for an example how memory safety can fail rather spectacularly.