Potential sub-goal: guidelines to avoid panics

[felix91gr]

The more I wonder about this, the more it makes sense to me: perhaps we want to make a broad guideline, or family of guidelines, aiming towards avoiding panics.

Because panics are game-over in Safety Critical, right?

There are a good few functions and operations in core that can trigger panics. Thanks in big part however, to the Rust for Linux work, most if not all essential operations should be available in a no-panicking form. We might be able to use those as footing for this set of guidelines.

How does that sound?

[PLeVasseur]

Seems like a reasonable sub-goal which many in safety-critical would agree with. 👍

[manczak-ifx]

In some cases panics can be used as a intended reaction to a system instability or even a potential attack what requires a common reaction (e.g. reset).
Important would be is to have a clear explanation for each panic that are expected in the code and have a clippy which demands a explanation to the panics so it is easy to identify unwanted panic points in the code.

[iglesias]

Citing CERT C++ on Exceptions and Error Handling since I think some of the decisions in there (e.g. "do not abruptly terminate the program", exception -> panic safety) could serve as inspiration.

[PLeVasseur]

Something @rcseacord mentioned on our call today --

It's typical in safety-critical to have a safety monitor or "watchdog" which is responsible for listening to a "heart beat" and/or checking outputs from software processes and restarting them in some fashion.

An example of this written by CodeThink in support of work they are doing for safety-qualifying a Linux distribution is their Safety Monitor written in Rust.

cc @felix91gr

[PLeVasseur]

Discussion during our call today draws a distinction between free-standing and hosted which also is a worthwhile thing to raise up when a panic is raised.

[PLeVasseur]

If developers are told to avoid panics at all costs then developers may choose to remove assert!()'s which is not great and could lead to developers removing those and then putting the system in a worse (or unknown) state.

• this is a personal strong concern of @PLeVasseur's given our thoughts to be more empathetic to developers in-line with many other Rust documentation / resources
• in past meetings there's been concerns raised by users of e.g. MISRA C that if guidelines are "too" draconian this can lead to lots of contortions in code which can lead to worse code that's more difficult to debug and maintain

Suggestion to handle similarly to unsafe{} is handled in Rust; have some justification which must be annotated explicitly.

• this could be enabled by careful use of the required categorization for key guideline(s) to force a justification at each possible instance that could lead to a panic

A further step may even involve some formal proof, not only an annotation with justification.

[PLeVasseur]

panic as a means of saying "we no longer trust ourselves" / something which is unrecoverable or at least speculatively unrecoverable

• leads to a place where we'd say this process / system should likely be gracefully closed and restarted

[PLeVasseur]

There's a subset of guidelines which should be written in a way to help guide developers towards usage of Rust that does not lead to panics for "typical" things we'd like to do using Rust

• this does not in any way bar the writing of guidelines which give guidance for places where we must or should have code which panics

[felix91gr]

A small tidbit I found on the Rustonomicon just now: #[panic_handler]. For future reading (I know very little about it, but it seems like it might be an important piece of this overall puzzle)

[senier]

If developers are told to avoid panics at all costs then developers may choose to remove assert!()'s which is not great and could lead to developers removing those and then putting the system in a worse (or unknown) state.

IMHO that's a matter of stating the guidelines appropriately. Sometimes assertions are used for situations that should never happen, in which case a shutdown (and potential restart through a watchdog etc.) might be the best reaction. However, sometimes you see people use assertions to document the precondition of there function. For those cases, the guidelines may opt for using Option/Result and explicit tests instead to avoid panics.

A further step may even involve some formal proof, not only an annotation with justification.

Proving absence of panic would definitely be the end goal.

[ojeda]

Because panics are game-over in Safety Critical, right?

I am not sure that is true -- it depends on what the panic consequences are. Panics may, in principle, be accounted for and/or expected in the design.

[PLeVasseur]

@senier, @ojeda --

Yeah, there's definitely more nuance that came about in our discussion we had in the coding guidelines meeting 2 weeks back, starting from this comment.

I'll also add a few more considerations that came up this week in some code review when considering where to panic or not that I'll capture here:

• The programmer passes an invalid parameter to a function.
  • For example, this could be like indexing a normal Rust slice. Should we panic for out-of-bounds in this case?
• A trait implementation does not follow the specification.
  • For example, this could be like having a function taking a parameter that implements the a trait that can only panic if the trait is incorrectly implemented.
  • This is akin to the standard library's HashMap, which can panic or otherwise behave in unexpected ways if the key's PartialEq or Hash implementations are wrong.
• A struct/module maintains internal invariants, and those invariants are broken. This would mean that there is a bug in the implementation of this struct/module.
  • For example, in the standard library this could lead to undefined behavior in numerous places without using a panic.

[ojeda]

What matters is whether the requirements are satisfied.

In a case like your "invalid parameter" one, if the function documents that is the case, then it is perfectly fine (and expected) to panic. If your end product doesn't allow panics for whatever reason, then using that function would be wrong, but it doesn't mean the function itself is wrong.

Sometimes I have seen claims that triggering panics always imply there is a bug. I don't think that is the case. It again depends on the requirements. My safety-critical design may be perfectly safe (as in functionally safe) with panics involved. My throwaway script may use panics because that is the best tradeoff. My test case for panics may expect to throw a panic. And so on.

Thanks in big part however, to the Rust for Linux work, most if not all essential operations should be available in a no-panicking form. We might be able to use those as footing for this set of guidelines.

By the way, thanks for the kind words @felix91gr, but I don't think Rust for Linux had a lot of impact on that -- most core functions as far as I remember were already available in fallible or unsafe variants. We definitely discussed quite a lot around fallible alloc (and many other things -- please see e.g. Rust-for-Linux/linux#2), for instance, but we ended up with our own alloc for flexibility.

Panics are of course heavily discouraged (see e.g. https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust), but we do have some Rust panics in Linux, including kernel configs that add panics, such as overflow checking (enabled by default at the moment) and debug assertions (disabled by default).

[senier]

What matters is whether the requirements are satisfied.

In a case like your "invalid parameter" one, if the function documents that is the case, then it is perfectly fine (and expected) to panic. If your end product doesn't allow panics for whatever reason, then using that function would be wrong, but it doesn't mean the function itself is wrong.

You are raising a very valid and critical point here! It's perfectly fine if a function panics if assumptions are violated. In that case the caller needs to ensure that those assumptions hold. This implies a couple of things, though: those requirements must be correctly and completely documented, the programmer using that function needs to read and understand this documentation and make sure the stated assumptions hold in all cases. Ideally, this whole process would be automated (e.g. deductive verification where for all call sites the assumptions / preconditions are proven). I don't think we are there, yet.

This manual process of ensuring preconditions of all called functions is currently done by humans and thus error prone. Until we have automated and widely used tooling for that, I believe that the value of safety critical coding guidelines is exactly to eliminated as many footguns as possible. This may include discouraging functions that panic due to violated assumptions and prefer fallible functions instead etc.

Sometimes I have seen claims that triggering panics always imply there is a bug. I don't think that is the case.

I agree that this is not true in this generality.