Igor Stoppa proposed the creation of a prioritised checklist of known issues relating to the use of Linux in safety applications at the 2023-10 Munich ELISA workshop.

Igor has written some 'seed documents' that begin to describe a set of known issues, and has suggested that ELISA host and manage a 'fork' of these documents, to be extended by contributions from ELISA and the wider open source community, and a register of items for the proposed checklist.

Document a generic process for ELISA working group activities, to facilitate collaboration and coordination between groups and make it easier for newcomers to ELISA to understand the context and results of a given activity.

An initial set of guidance notes is drafted in the WIki here:

https://github.com/elisa-tech/wg-osep/wiki/Process-for-ELISA-working-group-activities

The intended outcomes are to:

• a) Apply it to an example topic / activity,
• b) Write up the process in a PR, for inclusion in the repo
• c) Write up the results of a) in a PR, for inclusion in the repo alongside b) as an illustration

Looking at
https://github.com/elisa-tech/wg-osep/blob/main/Contributions/Interference_Scenarios_for_an_ARM64_Linux_System.md I feel that interference from the perspective of Trustzone and interference on common support infrastructure controller like interrupt management might be something to consider

Just tried to quickly draw this up to illustrate what I mean:

OSEP, Systems and Automotive WG start using github projects to track tasks and distribute work. The structure of the projects should have a common look and feel and need to be properly documented. Also the process in using it need to be written down.

This issue is there to have documentation (most likely in the workgroups repo of elisa-tech) how to work with github projects The issue may be moved based on discussion within OSEP and TSC meeting

As discussed in this PR, we need to decide the process for reviewing and adopting contributed content as ELISA content, and the criteria that should be applied when doing so.

Objective(s)

Describe a set of core requirements for Linux for scheduling of processes/tasks on the CPU, together with the key risks associated with this functionality and system-level design strategies, Linux design features or specific kernel configurations that can be used to manage or mitigate these risks.

Outcome(s)

Create documents in the OSEP GitHub repository describing:

• A set of core requirements for Linux related to process scheduling
• The key risks associated with using this functionality in a safety context
• System design strategies, Linux design features or kernel configurations that can be used to manage or mitigate these risks
• Additional risks or limitations that may arise from using the specified mitigations

Based on the following notes from discussion between Paul and Igor, document the proposed approach that we have been dicsussing in OSEP and a plan for how to build on and elaborate it in collaboration with the other WGs.

Goal is to have this written up in and shared with other WGs before the next Workshop (4th/5th June), so that we can discuss feedback and next steps at the workshop itself.

Introduction

Observation: many points of view and opinions, often not incompatible,
but applied to different situations and under different circumstances.

Proposed approach

1. Define in an objective way the problem at hand
   (i.e. use Linux within safety applications), based on facts that everyone
   can independently verify:
         - The document about HW (ARM64) and SW (Linux Kernel)
         - The document about requirements for FFI and availability

2. Create a rudimentary - but still independently verifiable - syllabus with
   a collection of known issues associated to the previous point, and the
   condition under which said issues will manifest themselves
   (i.e. the KNU, to represent those problems usually ignored/downplayed)

3. Provide guidelines that address the problem for what it really is:
   an all-around engineering challenge that must lead to the creation of a
   "product" (it doesn't have to be commercial, but it needs to satisfy
   functional requirements) that is also compliant with safety goals.
   (i.e. the document under review in PR 33)

Goals for ELISA

Describe a long-term, iterative, overall engineering approach to arguing
system safety for systems including a Linux component, with the
following general principles:

• Make claims about the safety of the system-including-Linux, rather than
  Linux-as-a-component
• Identify the risks and limitations that are unavoidable when using
  Linux as the basis of an operating system, and system design strategies
  for mitigating these (where they exist)
• Start with use cases where (for example):
  a) Safety requirements are largely or entirely assigned to other
  system components
  b) Linux is used in a redundant component of a fault-tolerant system
  design e.g. using a 2oo3 voting architecture
  c) Component failure in the Linux-based component can be detected and
  mitigated by other means

Next steps

1. OSEP (Paul) to write up a summary / framing document describing this
   approach and linking to the documents contributed by Igor.

2. OSEP to document a 'decision tree' to help guide system designers
   planning to use Linux as part of a safety application, identifying both
   the risks that are involved (checklist) and approaches for dealing with
   these (engineering considerations)

3. Arch WG to follow that process, singling out aspects of Linux that are
   the most invariant (or unavoidable), in the sense that they are likely to
   be receiving safety requirement whenever a safety goal depends on Linux.
   And also identify, for each Linux component, an alternate approach,
   e.g. through other HW or some other SW running either on separate systems
   or in a different HW mode. (effectively ensuring that the decision tree is
   indeed a tree and not a very straight stick)

4. LFSCS WG to do a deep dive into those Linux features identified by the
   Arch WG, in practice navigating the tree along the "path of Linux choices"