Minutes 23 May 2024

Host: Paul Albertella

Participants: Florian Wuehr, Igor Stoppa, Daniel Weingaertner, Phillip Ahmann, Mikel Azkarate, Sebastian Hetze

Agenda

Continue our investigation of spatial interference

Discussion

Igor: Updates to https://github.com/elisa-tech/wg-osep/pull/36

• This is an input to the discussion, being extended / refined in parallel
• Goal is to identify the potential interference scenarios
• Complexity of these is such that conventional risk evaluation methods are not useful

Interference that we cannot always detect is particularly problematic; we want to look at the categories of memory that can be affected by this sort of interference

• We want to start with userspace in the first instance, because it is more straightforward for us to get started, and will make this analysis more accessible to newcomers to the problem

When kernel initialises a userspace process it has to map a set of different memory types into the process map

• Providing memory areas for stack, heap, etc
• Mapping into this space the memory areas containing the executable, etc
• Some of these are mappings of kernel memory (for optimisation)
• After this has been initialised, it is possible that the underlying memory mappings may be dynamically changed by the kernel as a result of changes that are independent of the local process.

This means that a safety process, which needs to be certain of the integrity of this memory, will need to take at least some responsibility for verifying this at runtime. However, we may need something external (to the execution context controlled by the kernel) to confirm this. e.g. We could have an external watchdog with a challenge/response mechanism that a process uses to verify that the integrity of its code has not been compromised.

Basic principles:

• The kernel loads and initialises memory
  • But there is a chance this could be dynamically changed due to interference
• Our process needs to verify that memory on initialisation
  • e.g. Check that needed memory is available
• Our process then uses that memory
  • Could implement some local (to our process) measures to manage the allocated memory once provided
  • This could minimise exposure to errors / interference in the kernel’s memory allocation functionality
  • However the kernel could still interfere with this memory!
• Our process needs to verify the memory periodically or on certain actions
  • When, how and how often will be application-specific and level of safety integrity
  • e.g. Might need to verify on each access, or only on boot, or on a regular schedule