Skip to content

Minutes 14 Nov 2024

Paul Albertella edited this page Nov 20, 2024 · 1 revision

Host: Paul Albertella

Participants: Daniel Krippner, Pete Brink, Igor Stoppa, Gabriele Paoloni

Agenda

  • Publish previous workshop presentations
  • Review and publish 'Contributions' already in OSEP repo
  • Review status of PRs

Discussion

Add author and contributors to the published document

  • Can we automate this (e.g. with a plugin)

include other metadata?

What policy should we have on when material is published?

  • Currently publishes on merge to main
  • Could publish on tags / releases only

Add the names of the approvers

  • Could we automate this?

Should we ask Min to link to this from the main Elisa site?

Review criteria: Completeness, correctness and comprehensibility

  • Peer review by someone with the appropriate domain knowledge
  • May need both safety and Linux domain knowledge
  • Should we include reviewer bios to

Gab: Some subjective statements

  • Cover this by verifiability claims
    • Where a claim is felt to be subjective by a reviewer, then we need to substantiate it
      • or qualify it, to make it clear in what specific context the claims apply
  • Review against available technical documentation and the safety standards

Examples:

  • Concept of self-interference may need to be reframed
  • Some statements are very absolute, when there could be room for other approaches

Igor: Need to consider what the implications of putting an ‘official’ badge on a document from a liability perspective

Gab: If we focus on describing the risks that are involved in using Linux, and identifying possible mitigations, but avoid making specific statements about feasibility or suitability

  • e.,g. enumerate the limitations of cgroups (and all kernel code) rather than making a value judgement about whether it is a ‘good’ or ‘dangerous’ solution
  • describe the challenges objectively, and the limitations of any mitigations, and leave the decision about what is ‘safe’ to the system designer

Next time:

  • Igor: Each feature in the kernel carries a certain amount of risk, based on its complexity, potential set of interactions (and therefore interference)
  • Can we make a statement about how we might consider this in our approach?
Clone this wiki locally