Secure HW/SW Interface

Motivation

OS memory safety research

Memory safety for OS code:

  • OS designs based on safe languages;
  • Compiler techniques such as SVA-M to enforce memory safety for commodity OSs in unsafe languages;
  • Instrumentation techniques to isolate a kernel from extensions such as device drivers;

Singularity, SPIN, JX, JavaOS, SafeDrive, and SVA-M are examples of system that enforce a safe execution environment.

Common asumptions of OS memory safety research

Unfortunately, all these memory safety techniques (except Verve, which has very limited I/O and no MMU support) make assumptions that are routinely violated by low-level initeractions between an OS kernel and hardware, even if implemented in safe programming language. Such assumptions include:

  • A static, one-to-one mapping between virtual and physical memory;
  • An idealized processor whose state is modified only via visible program instructions;
  • I/O operations that cannot overwrite standard memory object except input I/O targets;
  • A protected stack modifiable only via load/store operations to local variables.

Possible attacks

A buggy kernel operation might overwrite program state while it is off-processor, and that state might later be swapped in between the definition and the use of the pointer value;

A buggy MMU mapping might remap the underlying physical memory to a different virtual page holding data of a different type;

A buggy I/O operation might bring corrupt pointer values into memory.

Reference 1

  1. Memory Safety for Low-Level Software/Hardware Interactions, Usenix Security, 2009. ↩
Created Jul 22, 2019 // Last Updated Aug 31, 2020

If you could revise
the fundmental principles of
computer system design
to improve security...

... what would you change?