Minutes 16 01 2025

Host: Paul Albertella

Participants: Pete Brink, Igor Stoppa, Daniel Krippner, Raffaelle Giannessi, Gab Paoloni, Sebastian Hetze

Agenda

Documents we'd like to write/publish & how to proceed:

• Guidance for reviewing documents published by ELISA
• Supply chain models & roles for products involving Linux / FOSS
• Linux Memory Management Essentials
• Using Linux in a Safe System

Conclude discussion of 'risk of interference' approach

Discussion

Igor: Transparency is important, in the sense that formal processes around safety tend not to be public: we have to trust the assessor

• For an open source project, we would like this to be as public as possible
• If the output of an evaluation of an open source project is not public, I can’t independently validate my confidence in it

So we don’t only want to share the criteria, we also want to share our evaluations

Paul: Define the criteria that need to be met in order for a document to be published

• If there is an ongoing discussion about the document that is not resolved, then it can be captured in an issue, and may be resolved in a future change

Daniel: Do we want a regular release cadence?

• Paul: The merge to main is what triggers the publish
• Might do some kind of formal release process in future
• e.g. To state that the documentation is at a level of completeness

Pete: Define some aspirational goals, but start with some concrete criteria that we can apply

• Could use the evolution of the criteria as an indication of when the complete set of reviewed documentation is ready for release

Action: Pete will start by defining goals and some initial criteria in a PR

Daniel: Frequently encounter confusion or strange assumptions about how open source is used in practice in a product context. Often involves a supply chain - with open source being a type of supply chain.

• Expectations about this and useful / not useful models for how it works exist
• e.g. The idea of a ‘certified’ FOSS project is common, but not always feasible, or meeting the expectations of a consumer
• The idea is to write about these expectations and models and identify what we believe might work best for Linux in a safety context

Igor: Summary if you don’t have a vendor to ‘own’ a FOSS dependency, then you ‘own’ it

Gab: SPDX can be used to track the BOM for a product, including licenses

• Sebastian: Need very clear provenance for components, including signatures / hashes to confirm who provides them
• Daniel: May also include things like AOU with which components are provided
• Gab: May help to describe supply chain, but not necessarily the accountability
• Daniel: Yes, this is a business problem, not a FOSS problem

Igor: Distinction between provenance / origin, and responsibility for making changes

• Manifests (output of the vendor / integrator) may help to record who is responsible for what

Action: Daniel: To start a PR with a draft for this, hopefully in Q1

Igor’s documents:

• Introduction requested by Gab
• Igor: Point of contention: Use of SELinux, and other features that are deeply entangled with other features of the kernel and exposed to userspace configuration inputs, can be double-edged swords
  • Might only want to use them in mixed-criticality or corner-case scenarios because there are potentially less complex / entangled alternatives (e.g. hypervisors)
• Sebastian: What is the ‘right’ choice for a given solution may vary
  • Choices about the risks that you want to take
• Igor: Might be safer to choose a system design where you can use a qualified component which is also less complex / less risky than the equivalent Linux features
  • Baremetal hypervisor like Xen is also very simple