-
Notifications
You must be signed in to change notification settings - Fork 8
Minutes 02 May 2024
Paul Albertella edited this page May 3, 2024
·
2 revisions
Host: Paul Albertella
Participants: Igor Stoppa, Pete Brink, Sebastian Hetze, Daniel Krippner, Daniel Weingaertner, Mikel Azkarate
- Begin investigation and document using process checklist
How and in what form should we capture the context / assumptions?
- Start by describing what we are doing in text
- Aim to have diagrams eventually, to make it easier to engage with
- Define the application context
- A userspace process that is performing safety function in a system
- ARM 64-bit systems; Intel 64 is likely to be similar, but the details may vary
- Does not apply to 32-bit systems, because they lack the linear memory map
- What assumptions are we making?
- The safety function involves storing some state in the memory space of the process
- i.e. the spatial integrity of the process is critical to the correct performance of the function
- e.g. an action must be performed if the stored value passes a threshold
- The memory that is used for storing the process memory is mapped into kernel space as writable pages (linear mapping)
- The code and data of the function are present in physical memory
- This will always be the case when it is executing on a core
- It can also be pinned to ensure that this is always the case
- Interference can come from any source
- Including systematic errors in the design or implementation of the kernel or another software component
- We cannot rely on deterministic behaviour of the kernel as a whole
- Individual aspects of kernel behaviour may be deterministic, but the size and complexity of the potential set of interactions for an executing kernel make it impractical or impossible to model deterministically
- What aspect of Linux are we looking at?
- Memory integrity of a specific userspace process
- What aspect of safety are we considering?
- Freedom from interference with respect to spatial integrity
If the kernel uses the linear memory map to access memory, then the protections that exist in the process memory map are irrelevant.
- The linear memory map is a map of (almost all of) the physical memory mapped into a contiguous virtual memory, which is used to implement the other (process-specific) memory maps
- This also means that process-level read- or execute-only memory designations do not apply to this mapping
- The kernel does mark the memory segments containing its own executing code as execute-only
- Hardware features that are intended to protect against malicious access to memory, not interference of the kind we are considering
Consider what the effect of spatial interference might be, and what strategies might be used to detect it
- Different types of content may be amenable (or not) to different strategies, and have performance impacts
Igor's suggestion: identify which kind of memory spaces a process uses (code, stack, heap, ...), and how an interference may manifest itself on each memory space.