Minutes 05 Oct 2023

Host: Paul Albertella

Participants: Igor Stoppa, Daniel Krippner, Gab Paoloni, Roberto Paccapeli

Agenda:

Update on
- Quantitative and probabilistic methods summary
- ELISA Workshop in Munich
Models describing Linux role in safety-critical systems
- Abstract OS model control structure for Linux [^1]
- Can we use models like this to describe kernel failure modes (e.g. the memory corruption problem) in a way that safety experts and kernel developers (and other interested parties) can understand?

Igor: The Xen example only assigns safety responsibilities to Zephyr, so it does not contribute to arguments about safety with respect to Linux
Paul: You might say that it could be useful as an illustration of ‘Enabling Linux in Safety Application’ without giving it any explicit safety responsibilities. But is that actually consistent with the goal of ELISA
Gab: Purpose of System working group was to consider a variety of use cases for Linux, including ones whether Linux has no explicit safety responsibilities
Igor: Would be useful for us to distinguish these different model of use:

Linux is present in the system, but has no role in any safety scenario
Linux is present and has an active role in a safety function, but no responsibility for ensuring that it is correct
Linux has responsibility for some parts of a safety function or functions
Linux has responsibility for all safety functions

Igor: What changes with these different models, is the level of availability that we can guarantee and the levels of responsibility for maintaining this e.g. Detecting an unsafe steering action vs preventing this from having a hazardous effect in the system
Not sufficient to talk about safety without considering the level of availability required for the specific safety function(s)
Establishing these at the start of a discussion / analysis is therefore essential Also very useful for a newcomers to ELISA to understand these things

Discussing proposed model for framing analysis of Linux-based operating systems Comments on this version of the model

Gab: Access Control: To some extent this may be provided by daemons in userspace - i.e. the Services and/or Service Manager in the diagram Paul: Agreed - perhaps we need to make a clearer distinction between access control at an application or service level, and access control at a user or CGROUP level
Igor: Not clear how this would show e.g. a workload accessing a filesystem Paul: Some of the interaction lines terminate at the group level, indicating that all of the boxes within have a common interaction. Need to make this clearer
Igor: Does this diagram intentionally omit a hypervisor? Paul: Yes. Do you think that this is always needed? Igor: No, but it is not clear where responsibility sits for ensuring safety in the system- e.g. who pets the watchdog? Paul: Perhaps we need a number of versions of the model corresponding to the different roles that Linux and other components have
Igor: May also be useful to add Network as a hardware component external system that the LBOS exchanges safety-related messages or data with as part of a safety function external hardware component that LBOS interacts with via a bus

Igor has a session immediately before Paul’s safety analysis slot, to discuss the kernel memory integrity problem This may work as a complement to Paul’s slot - Igor discusses the problem, Paul discusses how we can frame it and analyse it
Paul and Igor to work together on a slideset for the workshop
Gab: Will Paul’s session also talk about Quantitative and probabilistic methods summary? Sebastian Hetze took an action to write about this, and may have some progress to report next week, but Paul plans to touch on it at the workshop either way