Skip to content

Minutes 18 Apr 2024

Jump to bottom
Paul Albertella edited this page Apr 18, 2024 · 1 revision

Host: Paul Albertella

Participants: Florian Wuehr, Igor Stoppa, Pete Brink, Sebastian Hetze, Daniel Weingaertner, Mikel Azkarate

Agenda

  • "Using Linux in a Safe System" PR
  • Process and criteria for adopting contributed content [4]
  • Proposal for "Overall engineering approach" and next steps

Discussion

Sebastian reported that LFSCS desire a better defined roles / relationships for WGs

Sebastian questioning whether exclusive focus on kernel is necessarily the right approach

  • e.g. changing the kernel might not always be necessary to resolve a problem
  • Pete: And our ‘improvement’ might have a negative impact on another important characteristic

Sebastian: ELISA has tried to make it clear that we cannot make a ‘safe’ Linux kernel, but we can identify the kernel components (drivers, etc) that we might use, configure, etc

  • Igor: I have been focussing on kernel, but that doesn’t mean that other aspects of a Linux-based OS are not relevant or important
  • Sebastian would like there to be more protection features added to Linux
  • Pete: But does that mean changes to the kernel or things that we add outside?
  • Sebastian: I believe that there will necessarily need to be some features added to the kernel

Paul: Always need to balance different demands for a given system. Safety has to take priority where it is required, but that doesn’t mean that we don’t have to consider how it needs to be balanced with other considerations - there are trade-offs that may need to be made

  • Pete: Need to treat Linux as an untrusted medium. So if we want to use it as part of a ‘pipeline’ that is involved in a safety application then we need some kind of external program flow control monitor (e.g. the EGAS model) to ensure that the ‘nominal’ part of the system is working within its required parameters. But also need measures to ensure that the flow control monitor is performing as expected
  • Paul: Can we apply a similar approach to operating system functions (e.g. those involved in a GPU pipeline)?
  • Pete: Not sure that you can ever trust the kernel in a role other than as providing the nominal function reliably, and most of the solutions applied for use in a safety application will be application specific.
  • But there may be some mechanisms that you implement to support this that other can re-use Paul: For example having a framework to support monitoring of behaviour within the kernel that is important for my particular application

Paul: If we can't use 'traditional' approach to verifying the kernel (unit testing & code coverage) what can we do instead?

  • Igor: Simply running the system in different scenarios is insufficient - you also have deliberately create the failure modes that you have identified.

(Discussion to be continued)

Criteria for ‘accepting’ content into OSEP (or an ELISA) repo

  • Pete: This wasn’t a consideration for ELISA originally, because the planned focus was on landing changes in the kernel

Pete and Paul previously discussed the idea of having a fork of the kernel that focussed on providing a stable, verified feature set instead of trying to keep in step with mainline

  • Igor: This is difficult to sustain if you want to keep up with security and bug patches
  • Paul: The challenge is always that there is always a cost in maintaining a system built on Linux
    • If you follow the LTS branch model (as favoured by the Civil Infrastructure Project, for example), then you have to have someone reviewing and backporting security and other critical bug patches
    • If you stay in step with mainline, then you may have to deal with the impact of new features or altered behaviour

Paul: Rather than forking the kernel, a better approach is to have an OS that consumes a specific version of the kernel and maintains a larger integrated OS or 'distro' around it, with specific kernel configurations and other measures or mitigations

Clone this wiki locally