Minutes 09 Nov 2023

• Host: Paul Albertella
• Participants: Pete Brink, Sebastian Hetze, Igor Stoppa, Daniel Krippner

Agenda:

• 'Next Steps' from Munich Workshop [1]
  • Igor's 'Checklist of known issues' initiative
  • Establish document review & publication workflow
  • Build index of past ELISA results
  • Basil requirements tool
• Vice-chair for OSEP?
  • Suggested new role for ELISA WGs
  • Serve as proxy for WG chair when unavailable
• 'Proven in use' PR from Sebastian [2]
  • Review status

Discussion

Pete: Re: review and publication workflow - most important purpose of processes in a safety context is minimisation of systematic error

• Igor: Does this not require a model of what is causing the systematic error
• Pete: Assumption is that if software is wrong, that is because we specified it or designed it wrong (or inadequately)
• Igor: Absence of formal design does not mean absence of design, it means that the design is articulated in different ways (e.g. read the code!)
  • It could be argued that code-as-design is good, because it minimises the potential disconnect between design and implementation
  • Best way to convey information about software will be audience-dependent
• Igor: If we discuss something at a level of abstraction too far removed from the subject, it can be difficult for participants to understand the challenges

Igor: I am working on a summary (60+ page) of Linux kernel interactions with ARM64 hardware

• Will include a list of known issues
• Not claiming to be comprehensive, but a good starting point

Expect it to be released under a CC or equivalent licence to allow it to be referenced and re-used

• Could be a useful frame or reference for discussion about e.g. interference
• Also working on a template for safety requirements that hopes to publish

Paul: Having a list of known issues / limitations is a starting point

• Some of these may be disqualifying for certain safety-related applications
• Some of these may require kernel design changes to resolve or even mitigate

Igor: Tried to write this document in a way that Linux kernel developers can engage with

• Important for them to understand this, and why users (like us) have problems with some aspects of the Linux design
• e.g. effective separation of subsystems could enable work to happen, driven by the needs of critical system developers, that contributes back to the kernel
• May require some architectural changes to the kernel

Also requires changes to expectations about kernel development process - what documentation, testing is required for a change to be acceptable, and what documentation needs to exist for existing functionality.