Minutes 29 Feb 2024

Host: Paul Albertella

Participants: Igor Stoppa, Pete Brink, Luigi Pellecchia, Daniel Weingaertner, Florian Wuehr, Gabriele Paoloni, Sebastian Hetze

Agenda:

Discussing issue raised in the GitHub repo, in relation to the checklist and source of interference. Do we need to consider interference from other (more privileged) components with Linux in a system implementing the Trustzone model?

Pete:

• Igor’s comment that things get more safety critical as we get closer to the hardware is an important thing to consider
• The OS is (relatively) close to the hardware in relation to the application software, so it can be assumed to have a higher level of criticality
• This might mean that e.g. a hypervisor needed a higher (or equal) level of criticality in relation to the OS
• Linux is an anomaly in this respect, because it cannot (currently) claim that it provides the expected level of criticality
  • i.e. We would normally expect it to have a higher or equivalent ASIL to the applications that run on it

Gab: But there are system architectures where the OS has a lower integrity level than e.g. a ‘safe’ middleware

Paul:

• ASIL / QM labels in this kind of diagram can lead to unproductive discussions, because we end up arguing about e.g. what QM means and why it doesn’t apply to Linux
• Need to consider what roles and responsibilities components have in the system as a whole - does not necessarily require a strict hierarchy

Pete:

• ASIL rating is an expression of the requirements for a component in a system, in relation to an overall safety application
• Hence a label on an architecture diagram is a statement of the system architecture design’s requirements on the labelled component. Regarding Trustzone components and interference
• We should acknowledge that these may be a source of interference
• We can note the difficulty of detecting and dealing with this kind of interference within the kernel
• May be better to invest in making these components ‘safe’ (able to prevent or detect this) instead of trying to build this into the kernel
• Reasonable to state that this kind of interference (from higher privilege components in the Trustzone model) could be designated out of scope for a given claim about Linux, but this would still need to be considered by a system integrator

Pete: ASIL evaluation is based on severity, controllability, exposure

Paul: This kind of thinking can be applied to OS responsibilities (external or internal checks) e.g. A watchdog could allow us to detect

Igor: Yes, but… it is not possible to do this for every responsibility of the OS

The use case for us to consider for next time:

“I have a bash process (representing a typical process with an assigned safety function) that I would like to protect from interference with its working memory.”

Hope is that we can use Basil to help record outputs of analysis in a structured way

• Luigi: Basil should be available for us to use online by next meeting

**Note that Daylight saving starts in the US March 10th, so OSEP meeting times may be out of whack until DST observances align **