@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.
@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.
Real problem there was not the fact the kernel panic happened but more the fact that recovery strategy that does not require manual intervention did not implemented.