Skip to content

Minutes 09 May 2024

Jump to bottom
Paul Albertella edited this page May 9, 2024 · 1 revision

Host: Paul Albertella

Participants: Sebastian Hetze, Luigi Pellechia, Pete Brink, Gabriele Paoloni

Agenda:

  • Continue our investigation of spatial interference

Discussion

Aiming to consider:

  • Effects of interference
  • Mechanisms of interference
  • Strategies for preventing / detecting interference

Assume that the kernel’s memory management model is working as expected

  • i.e. that userspace processes have their own protected memory maps

Threat is that kernel may violate these protections

See Codethink article for discussion: https://www.codethink.co.uk/articles/2020/investigating-kernel-user-space-access/)

See kernel self-protection docs for more inputs: https://www.kernel.org/doc/html/v4.14/security/self-protection.html

Two approaches:

  1. A way that we can prevent or detect (at runtime) the kernel writing to the user-allocated pages via the linear map
  2. Rules that we can enforce in the kernel code that prevent this, using build-time checks or static analysis

Problem: 2) does not mitigate unintended misbehaviour by the kernel (or a driver) due to e.g. a random hardware fault or a bug

Categories:

a) Corruption of the executable code (machine code instructions, text and data segments) in memory b) Corruption of the stack or the heap memory of the userspace process c) Corruption of data in the kernel associated with the userspace process (task descriptors) or with the kernel’s own data structures

The effect of corruption in these different categories is detectable in different ways e.g. c) might cause the kernel to crash, which would need an external detection and mitigation strategy

Assumptions / exclusions:

  • Hardware faults are out of scope - we assume that there are external mechanisms at a hardware level to reduce the probability to an acceptable level
    • What hardware mechanisms are sufficient here? This is an 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 are assuming that the Linux memory model works as designed to prevent this

Work-in-progress notes updated in the Wiki

Clone this wiki locally