Minutes 04 Jul 2024

Host: Paul Albertella

Participants: Florian Wuehr, Vivith Parlattaya, Daniel Weingaertner, Igor Stoppa, Gabriele Paoloni, Olivier Charrier, Lukas, Sebastian Hetze

Agenda:

• Conclude principles vs hazards discussion from last week

• Resolve remaining issues and/or agree next steps for pending PR

• Continue spatial interference investigation

Discussion

Splitting the PR seems useful

• Outstanding on comments are on the First Principles

• Submit the other files in another PR?

Igor: The explanation to back the principles is in the other files

• This is where the real detail (which merits review) can be found

Olivier: Thinking about this from the perspective of a system integrator, organising the points into hazards, potential mitigations and strategies or methodologies, and which of these require decisions as part of system design or integration

Igor: Wanted to emphasise that Linux alone is not sufficient

• Document should not rely on anything that is subjective - statements of sufficiency tend to be subjective

“The git tree that you can pull from the Linux kernel project by itself, does not provide the evidence that would be required to make a safety claim.”

Lukas: Just call them “assumptions to my Strategy”

• Linux can be used in safety-related systems. It depends on the strategy. Here is one of many strategies…

Daniel: We are trying to achieve something constructive here - the ‘principles’ are very discouraging as a first impression. If we want people to engage with the details, we should try to balance these with more positive statements.

Igor: I don’t want to encourage someone to do something risky - using Linux ‘as-is’ is not something that we want to encourage

Lukas: Your words will not stop this behaviour if organisations do not have a suitable safety culture

Igor: What would it take for ELISA to back a set of statements?

Paul: The process of having a document that is accepted by ELISA as a community is different to ELISA backing it as an ‘approved’ safety approach that could be used as part of a safety claim

The goal was to subject these documents to some level of peer review (which could be the PR process) before publishing them as ELISA documents (rather than contributions).

Gab: Would prefer to frame the message in a more positive way, while still highlighting the engineering gaps.

Igor: If ELISA cannot tell people how to make Linux safe, then we can at least identify ways in which it might not be safe

Next steps:

• Igor to make links between the principles and the other documents

• Igor to split the other two documents out into a separate PR

Should we debate them here rather than offline comments in the PRs?

• e.g. Take the points one by one and examine the supporting sections of the other documents

Paul: To break the points up into categories and propose a structure for us to proceed with

Lukas: What is the motivation for addressing these interferences? We should focus on specific functional property for the kernel

• EDIT Paul: I assume that this means: consider the possible interferences in relation to a specific function, rather than trying to argue "freedom from interference" in the abstract.

Vivith: I am specifically interested in the ability of Linux to deal with potential spatial interferences - if we don’t understand the ways in which spatial interference can happen, it is difficult to frame a safety claim that is impacted by this