Minutes 21 Nov 2024

Host: Paul Albertella

Participants: Daniel Krippner, Pete Brink, Igor Stoppa, Gabriele Paoloni, Vivith Parlattaya

Agenda

• Approach to managing 'per-feature' risks
  • See notes below
• Publish index of previous workshop materials [1]
  • New PR from Philipp [2]
• Publish Contributions as official ELISA guidance [3]
  • Agree and document review process / criteria
  • ARM64 Interference Scenarios PR [4]
• Other PRs [5]

"Each feature in the kernel carries a certain amount of risk, based on its complexity, potential set of interactions (and therefore interference). Can we make a statement about how we might consider this in our approach?"

Igor: Enabling a feature, because it has some advantage, also introduces a new set of risks.

• For example: SE Linux

Our attitude to the risk that this represents may be subjective, and the level of risk that it represents for a given use case may vary.

Higher complexity (and the number of features implemented) in components both increases risk and makes it more difficult to reason about a system.

An important consideration is the potential for interaction with these components

There is no generic qualified version of Linux as it is made available (as source code), so we must always treat its use in constructing a system as a risk to be managed.

Gab: An introduction like this might make the Interference document easier to understand.

Gab: when we talk about interference, we typically refer to elements of different integrity .

• We may have a single user process that has a safety integrity requirement, which may be interfered with by the kernel or other user processes
• We may have a kernel thread that we rely on which might therefore have an integrity requirement

Igor: Deliberately not proposing solutions, beyond giving examples, because what is appropriate or effective for a given system will vary.

Add a preamble to the document, stating that the kernel is considered a lower integrity component which may interfere with one or more higher integrity components of a safety-related system. There may also be elements of different integrity within the kernel.

Igor: CGROUPS, SELinux, namespace are all deeply entangled with the core elements of the kernel (high coupling factor). This means that having them enabled always introduces an additional level of risk. They are also involved in allowing or disallowing functions at a very low level, which can inadvertently prevent a higher integrity process from performing a function.

Pete: Would reducing the level of entanglement in the kernel help to reduce the risks? Could we define the interfaces between the elements more clearly, for example. This can be the beginning of a strategy for managing this.

Igor: These components are intended to alter the behaviour of functions with the kernel.

If we can describe these interfaces and specify what constraints should apply to them, this may help us to make arguments about them, and improve their integrity