Minutes 30 Mar 2023

Host: Paul Albertella

Participants: Pete Brink, Igor Stoppa, Gab Paoloni, Raffaele Giannessi, Phillipp Ahmann, Kate Stewart

Agenda:

1. Review the notes that Igor posted on the list about [1] regarding his thoughts from last week (which I haven't been able to access yet)
2. Start work on (or at least plan) our next attempt to apply STPA to an aspect of Linux,
3. Decide how we want to ask for inputs and/or participation from the wider ELISA community for (2)

Notes that Igor was sharing were from LFSCS: https://docs.google.com/document/d/1bzLMpbYACe7HgD57AfjrR8SFRqMvP9gtKiGLCgMrKtw/edit

Proposing one or more ‘default’ system partitioning models as an assumed context for analysis would be a good starting point

• Use this to clarify which OS functions / responsibilities are in scope

Pete: Proven in use argument based on statistics (e.g. IEC61508 part 7 annex D), but amount of time / distance covered maks this prohibitive

Igor: What about a proven ‘not in use’

• show that parts of the OS are not used for a given set of functionality? e.g. deliberately make those portions non-executable / unavailable
• Reduce opportunities for interference by reducing scope of what is accessible

Paul: Why use Linux (if you are going to then reduce its scope dramatically)?

Motivations for using Linux:

• Availability of drivers for hardware
• Licence cost
• Developers with relevant experience
• Prototype development often uses Linux
• Automotive OEMs also use Linux on non-safety systems
• Use of open source development tools such as QEMU
• Android

What should we pick as a use case (or class of use cases)?

• Automotive WG's use case - cost saving: add safety responsibility to an existing non-safety system (IVI)
• Minimal Linux system for a dedicated safety function

Igor: If we start from a minimal system partitioning concept then we lose nothing - we can still exclude certain areas from our analysis.

Phillip: Argument that open source software practices (transparency, ‘many eyes’ principle) can arguably offer advantages over closed source software - same risks are present in the closed source, but less visible

Pete: Complex systems / software can be problematic in a safety context because it is harder to reason about such systems and they may have greater technical debt

• Argument: If you use relatively simple pieces to build a complex system, you can verify them in detail and include safety mechanisms
• Paul: But you could equally argue that a complex, demonstrably capable, but not 100% verifiable component in combination with simple, verifiable components in a monitor / safety mechanism role might offer equivalent (or greater) safety than a system entirely compose of simple components
• Igor: e.g. We could use runtime verification functionality recently added to kernel
• Gab: Yes - model the required behaviour in STPA and then implement monitoring to detect when system is not satisfying it - trigger a safe state
• Reactor concept for RV described here: https://docs.kernel.org/trace/rv/runtime-verification.html#runtime-monitors-and-reactors

Possible first use case model for us to consider:

• Linux has some kind of safety-related responsibility
• We don’t rely on it always being able to deliver on that
• When it can’t, we need to be able to detect that and reliably trigger a safe state (that is outside of our scope)

Igor: Some Linux features in kernel (e.g. CGROUPS, RT patch) can be valuable, but we can’t assert that these features are ‘safe’ Paul: This should be OK, provided that we do not rely on such features absolutely - i.e. they form part of a safety mechanism, but are not the last line of defence