Minutes 27 Jun 2024

Host: Paul Albertella

Participants: Igor Stoppa, Vivith Parlattaya, Gabriele Paoloni, Raffaele Giannessi, Olivier Charrier

Agenda:

• Conclude 'design elements' discussion from last week

• Status of pending PR

• Discuss 'First Principles' from this PR

• Continue spatial interference investigation

Discussion

Design Elements discussion: What is the intended outcome?

• Finding a way to identify and/or describe discrete aspects of Linux that we are considering as part of a discussion or analysis
• Came out of a discussion about ‘core parts’ of Linux, which was intended to help us prioritise which aspects we should look at first

Gab/Paul: Olivier suggested that we differentiate between ‘design elements’ of a system and ‘integration elements’ that describe how a number of design elements interact

• Olivier: Integration element would show how a risk / hazard that arises from using elements together is addressed or managed in your system design

Igor: Intention with PR is to set out what can be stated strongly, not as a matter of opinion but as something scientifically provable.

Paul: Can we describe Linux in terms of ‘functional elements’ : functionality that it is intended to provide?

• Igor: Yes, but ultimately it is monolithic, so this doesn’t let you avoid some of the limitations / problems that this introduces

Gab: Danger that some of the ‘First Principles’ can be interpreted as conclusions about an particular usage rather than facts

Igor: KASAN as an example

Gab: Discussion here

Igor: Perhaps reword as: “None of the available mechanisms within the Kernel - either individually or in combination - can give complete protection from complex systematic corruption of writable memory for all uses of Linux”

Igor: You could claim with good confidence that it does offer protection of code

Olivier: Identify hazards as part of the analysis of a functional element, which may be intrinsic to that element or inc combination with other elements

• An integration element describes how these hazards are managed

Igor: My approach was to start from the hardest problem (hazard)

• Identify which parts of Linux do not have such issues
• Solutions to a hazard in one element, that involve another element that has hazards of its own, may be problematic

Olivier: Could have an integration element called “Mitigating memory corruption” which captures the strategies that you can use to address the hazards

• Some of these could be partial - with aspects that need to be resolved by other means

Igor: Idea was to make strong statements that we can challenge with counter-examples

Olivier: Could for example address memory hazards by devoting a lot of effort to managing these hazards in your application. All OS have this problem.

Gab: Could we rename ‘principles’ as ‘hazards’ in the PR?

‘Principles’ could describe how you approach the problem, which requires you to deal with the identified hazards, but also identifies which aspects of the OS you can reasonably rely upon

Igor: Want to keep the statements as strong but happy to rephrase them for clarity