Gregory's Server@marcan Null deref?
Like, some `switch` construct got optimized into kind of `foo[bar].doCrap(ctx, data)` construct? But the `foo[bar]` kind of construct without default pathway can happen in Rust anyway if that thing constructed dynamically (e. g. by other earlier part of arriving data).
this can be a common situation for some "rules engine" or other high-level code execution branching infrastructure.
Does Rust can enforce "always have a meaningful result for `foo[bar]` construct?
|
Top-level
 10 comments
@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. |
@koteisaev There's no mention of an indexed array. Rust guarantees that nothing can be NULL at compile time. If you need to have optional values then you have to use Option<T> and the compiler forces you to choose how to handle the lack of value.
For switch statements and such, Rust requires them to be exhaustive or have a default case if that is required for correctness (e.g. because a value is returned).
Array/slice indexing with [] *can* panic (which is still a BSOD but at least guaranteed not an exploit) but it is possible to ban that in the compiler/linter and enforce the use of the .get() method which returns an Option<T>, and such policy would be a good idea for critical kernel code. You can set up a Rust build such that it is *impossible* for any operation to panic, e.g. by making the panic symbol undefined so the project fails to link if it is referenced. This even bans things like unchecked integer division by a non-constant (since div by zero is a panic). All of the panicking operations would have non-panicking versions that you use instead.
@koteisaev There's no mention of an indexed array. Rust guarantees that nothing can be NULL at compile time. If you need to have optional values then you have to use Option<T> and the compiler forces you to choose how to handle the lack of value.
For switch statements and such, Rust requires them to be exhaustive or have a default case if that is required for correctness (e.g. because a value is returned).