Minutes 20 Jun 2024

Host: Paul Albertella

Participants: Igor Stoppa, Pete Brink, Sebastian Hetze, Florian Wuehr, Mikel Azkarate, Olivier Charrier, Vivith Parlattaya, Michael Armbruster, Daniel Weingaertner

Agenda

• Takeaways for OSEP from the Lund workshop
• Status of pending PR
• Discuss 'First Principles' from this PR
• Continue spatial interference investigation

Discussion

Takeaways from the workshop

• Interesting discussion around the ‘First Principles’ proposed by Igor
• Idea of using ‘design elements’ - functional decomposition of the kernel instead of breaking it down by structural units - as a way to divide up and prioritise what we look at

Igor: Could also look at how the functional elements of the kernel / or a process are built up at runtime

• Gab: Looked at something similar in LFSCS: https://github.com/elisa-tech/wg-lfscs/blob/main/address_space_integrity/address_space_integrity.md
• Pete: This describes what it does, do we also need to describe what it should do
  • Gab: Goal of this was to investigate how Linux behaves
  • Could then make some claims and then evaluate these against this
• Igor: This is a top down approach - problem is where do we stop?
  • Start at bottom and work up
  • Pete: Problem is that if you only start from code and what it does, this does not examine what it is intended to do and how it could fail to achieve this

How would we characterise the ‘functional design element’ that we are investigating at the moment?

• Vivith: Is this in the context of a Safety Element Out Of Context?
  • Paul: Not yet - we are considering this from a general perspective, not for a specific safety standard yet
• Vivith: Do we have a set of requirements?
  • Paul: No - part of the problem with an OS is that the applicable requirements are dependent of the system and applications you are considering
• Olivier: We can define e.g. integration requirements for an OS that describe what you need to verify when you integrate an application on it
  • Might be better to describe integration elements for Linux, rather than design elements
  • Might define some restrictions or conditions of how an element is used
  • Focus on identifying risk rather than solving it in the first instance
    • Later identify design elements that can be used to mitigate these risks
  • A way to list the risks and break them down into these elements
  • There will always be gaps - system designer needs to work out how to manage these gaps and the risks that are entailed - or at least document them
• Distinction between integration element and design element
  • Integration element is a combination of design elements
    • e.g. Memory is a common aspect of an integration element
• Gab: Could an integration element be a set of safety requirements assigned to Linux?
  • e.g. Initialising the kernel address space correctly
• Olivier: Need to draw a line to separate our area of concerns (Linux) from the hardware
  • e.g. Given a device tree…
  • In some cases there is a stronger interaction with particular hardware (e.g. CPU architecture), others are more generic
  • Identifying where these lines are, and how ‘clean’ the lines are
• Drawing these lines, and identifying where there is uncertainty, can help us to identify where we need expert input from e.g. Intel / ARM on specific details, and common
• Paul: Can we use this to frame the work that has already been done?
  • Olivier: Yes, e.g. role of the Watchdog, memory management, etc
• Olivier: Describe risks as part of the integration element, then show how these are mitigated in a final design
• Igor: Is this language going to be understood by others in the safety / software community?
  • Olivier: Not necessarily, no - it is not standardised
  • Pete: The concepts do exist in software engineering, but the terminology may vary. Could point to SWEBOK for example.
  • Agree on a set of terms and define them
• Igor: How does this work with the investigation we were doing?
  • Paul: We could apply this framing / terminology to the documents that Igor has written - distinguish between the design-level and the implementation-level aspects