Minutes 15 Feb 2024

Host: Paul Albertella

Participants: Igor Stoppa, Pete Brink, Luigi Pellecchia, Daniel Weingaertner, Florian Wuehr, Raffaele Giannessi

Agenda:

• New PR from Igor (Checklist for Safety Claims)
• Next steps with this and other contributions
  • Feedback on documents having read them
  • Can these be basis of an ongoing and useful WG activity
• Paul bandwidth issues until end March (at least)

Discussion

• Luigi - talk about Basil has been accepted at OSS NA Summit Would like to work through an analysis of e.g. a syscall captured in Basil Is this something we could contribute to in OSEP? Could we pick something simple to work through and apply the safety checklist? Track specifications/ documents with Basil
• Igor - Requirements should not be stated directly in terms of an implementation
  • Not jumping straight to a specification
  • Current documents are stating requirements more at a system level - may not always be (fully) satisfied by Linux
• Paul: Use Basil to record requirements at system level and trace these to components and specification
• Igor: My favourite is the one previously mentioned: corruption of physical memory
• Paul: Can we break this down into parts that Linux can (theoretically) address and things that would need to be e.g. addressed by hardware or assumptions of use
• Luigi: Basil has been used so far only with man pages (as specifications) mapped to tests and to e.g. functional safety requirements
• Man page is not a requirement and is not sufficient as a specification, but it can be useful input if we want to verify that the functionality described is a) present as described and b) fulfils our requirements.
• Could start from the syscall and work down, or work up from the bottom (physical memory)
• Igor: Would like to avoid the “let’s start with something simple” approach
• Paul: What can we use as a starting requirement or set of requirements? “I have a bash process (representing a typical process with an assigned safety function) that I would like to protect from interference with its working memory” Threats to this:
• From other user processes (including other safety-related processes)
• From the kernel

Paul raised ongoing problems with bandwidth to work on ELISA, which may mean that meeting continue to be every 2 weeks.

• Luigi: I could help to moderate the meeting when Paul is not available.
• Paul: Thanks! That would be helpful

Next meeting will be on 29th February.