Minutes 03 Oct 2024

Host: Paul Albertella

Participants: Peter Brink, Vivith Parlattaya, Igor Stoppa, Mikel Azkarate

Agenda:

• Use of LLMs to make safety docs more accessible
• Publishing an index of previous workshop presentations
• Implications of randomisation (for security) on safety
• Status of PRs

Discussion

Vivith: Understand why we try to take a neutral position in discussions and avoid talking only about automotive. Would it make sense to talk in terms of IEC 61508.

Paul: Happy to talk about IEC 61508, but try to talk in terms of the processes that we can use with respect to Linux and how they contribute towards a safety argument / case, rather than how we comply with clause X.

e.g. What would a good architecture document look like and how can we encourage open source projects to adopt this kind of approach?

Pete: Standards like 26262 give us some clear guidelines about what is good architecture

Paul: But in this case the architecture exists…

Pete: Describing the nominal architecture of the OS and the safety architecture of the additions or modifications might accomplish what the standards expect. This might help us to identify where the nominal functions / interfaces would need to be extended to support the safety architecture.

Igor: First we need a definition of a minimal Linux-based system. Then we can analyse the components and their roles, and possible implications of these for safety. Then we can understand the implications of adding new functions.

Pete: We are describing a process!

Igor: Some guidance for the Features group on documenting the findings and the steps that were taken to reach them. If they can write them up in some form, then we can review them and make suggestions for improvement.

Mikel: What is the issue with randomisation from a safety perspective?

Igor: If you have a certain memory layout, and you analyse the risks of a buffer overflow with that layout, you can verify that critical functions are not compromised by this. Randomisation may change the risks, because critical data may be in a different location.

Pete: Randomisation can only be part of a wider solution

Example of an architectural decision