Minutes 30 Mar 2023

Host: Paul Albertella

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

Agenda:

• 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)
• Start work on (or at least plan) our next attempt to apply STPA to an aspect of Linux,
• 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