Minutes 19 Dec 2024

Host: Paul Albertella

Participants: Igor Stoppa, Gabriele Paoloni, Vivith Parlattaya, Nagamahesh Gamidi

Agenda

• Migration of ELISA meetings to new LFX Zoom system
• Add details to workshop documentation
• Continue discussion of 'risk of interference' approach

We are switching to a new Zoom platform for meetings starting form next year:

• https://zoom-lfx.platform.linuxfoundation.org/meetings/elisa

The next OSEP meeting will be 9th January

Igor will review the PR from Phillipp

'Risk of interference' approach discussed in last meeting

Igor: Specific point may need to be made about not turning on all of the available mitigations / protection features of the kernel if you can manage the risk in a different way, because these ‘deeply entangled’ features may add a level of risk themselves.

e.g. Using a hypervisor in conjunction with Linux

Gab: A clear introduction about the context(s) that we are considering. For example, mixed criticality means that some of these features are necessary.

Difficult to not have a mixed criticality system with a Linux-based OS

• e.g. will have journaling services, etc, which are unlikely to have been developed to the desired safety integrity

Containers do not solve all of the problems, but they can help to address some of them

Igor: Also if out-of-context qualification relies on a particular configuration then allowing the end user / integrator ‘play’ with these potentially devalues the testing / analysis done for the out-of-context qualification

e.g. SE Linux relies on a defined set of rules for a defined set of users

Rules can be useful but they can also frustrate users / integrators, leading them to subvert them in order to achieve their implementation goals.

Igor: Complex rules can also make it harder to build a safety case that can be verified. But e.g. generating rules using a tool might make it easier

It’s also hard to analyse SELInux effectively because it is so deeply entangled

The possibility of having multiple interacting security modules makes this work

Hypervisor approach could e.g. allow applications in different VMS to talk to each other

Rely on the hypervisor to implement the constraints, and use Linux as required within the isolated VMs

Paul: Feels like moving the problem around “use Xen or Zephyr to manage the safety bits”, but it is consistent with the idea that safety is a system problem.

Vivith: Can hypervisor system ensure time criticality, for hard realtime systems?

Igor: Not directly, but it can mean you can solve the problem somewhere else. Linux is not particularly good at coping with interference, so if we can use another technology to help with that, we are free to focus on the problems we are best able to solve using Linux. Or allowing collaborating Linux-based systems with a tighter focus to interact within clear constraints.