Agree and document overall engineering approach to safety for Linux

[reiterative]

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"

[igor-stoppa]

ACK