Minutes 10 Aug 2023

Host: Paul Albertella

Participants: Pete Brink, Gab Paoloni

Agenda: Safety Analysis framing for a specific safety mechanism

Paul: Progress on related topics in in other ELISA WGs?

Gab: Update on Safety Architecture WG

• Original goal of kernel safety analysis: Safety analysis that can be pushed upstream
• What is the purpose / goal of this?
  • Addressing gaps in documentation
• Problem: using STPA to do this is over-formal and a barrier to participation
• Igor Stoppa has suggested an alternative: engage kernel experts with what we are doing by focussing on Runtime Verification Monitor
  • Experts identify the key functionality within the kernel that needs to be monitored
• Question: how do we justify the use of the monitor?
  • Does this require safety analysis?

Pete: Is this program flow monitoring?

• This is the model that has been followed by some of his customers
• Gab: Yes. Risk is that there is behaviour that we are not monitoring that could violate the safety goals
• Pete: Key is that the monitor is safety-rated, so must be developed in accordance with a standard, but the thing being monitored doesn’t necessarily need to be anything more than QM
• Paul: Provided that we have identified the failure modes of the QM component and can demonstrate that the safety mechanism(s) manage these

Gab: Reverse engineering the kernel is tremendously challenging

• Pete: And that should be concerning in a safety context, because simplicity is strongly recommended
  • Gab: But if we accept that the kernel is what it is, and that it has evolved a complex design to achieve particular (non-safety) goals, can we design a simpler component that we can use to ensure that it is not violating a set of safety goals
  • Gab: Safety analysis inside the kernel reveals dependencies on many non-critical functions (e.g. printk) that are not directly involved in the safety function, but may potentially corrupt the internal state of the kernel, causing unspecified behaviour
  • Using the monitor we can verify that the expected / specified behaviour is observed
• Gab: Use this to qualify a given kernel subsystem
  • Paul: Might be clearer to talk about a kernel function, rather than a subsystem, because there may be dependencies between subsystems, and these are not guaranteed to stay the same
• Pete: Is there a way to make Linux work more like QNX? Isolate kernel functions so that we don’t have to worry about the possibility of interference?
  • Paul: Possible but a potentially huge amount of work
  • Pete: Can we use the understanding we gain from using the RVM to cut down the scope of the kernel that we build / configure, to reduce the possible set of interferences? And maybe rewrite critical drivers as userspace drivers?

Gab: Two approaches using this model: per-use case analysis with a limited set of functions in the kernel, or building up a more comprehensive set for a generic OS component (as a SEooC)

• Gab: I can focus to explain why the RV Monitor can actually protect from interference from inside the Kernel, because otherwise the RV Monitor does not provide much value

Paul: I am away on holiday for the next two weeks, but please can you start a discussion on this on the OSEP mailing list, as there are many more subscribers there than are able to join weekly meetings, who may be able to engage with this idea.