spatial kernel userspace

Safety analysis: Spatial interference via kernel corruption of userspace memory

Introduction

This is a work-in-progress record of the OSEP working group's analysis of the potential for spatial interference with a userspace process via memory corruption by a kernel task.

Context and assumptions

(based on the list in [Process-for-ELISA-working-group-activities])

1. 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

2. 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

3. What aspect of Linux are we looking at?

• Memory integrity of a specific userspace process

4. What aspect of safety are we considering?

• Freedom from interference with respect to spatial integrity

5. What are we excluding from scope (for this analysis)?

• Hardware faults
  • We assume that there are external mechanisms at a hardware level to detect faults and to reduce the probability of undetected faults to an acceptable level
  • Need to consider:
    • What hardware mechanisms are sufficient here? This is an assumption of use (AOU)
    • What responsibilities might the OS have with respect to these?
    • Action: Paul to document this in an issue
• Corruption of userspace memory by other userspace processes is out of scope
  • We assume that the Linux memory model works as designed to prevent this

Problem statement

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

Inputs

• Documents in Contributions
• WIP addition to these
• Kernel self-protection (Linux docs)
• Investigating kernel user-space access (Codethink article)

Interference categories

Category A

• Corruption of the machine code representation of the kernel / userspace binary executables in memory
• There are several (including hardware-level) protections for this, so this is considered lower priority

Category B

• Corruption of the user process address space by
  • a kernel mode task
  • a hardware fault - out of scope
  • another userspace process - out of scope
• Potentially most difficult to detect and mitigate
• Application could take some level of responsibility for checking integrity of its data
• Stack corruption may need to be detected by mechanisms implemented by the compiler

Category C

• Corruption of the kernel address space by
  • a kernel mode task
  • a hardware fault - out of scope