LLVA OS

References:

2006-LLVA-OS 1

2003-LLVA 2

Idea of LLVA and LLVA-OS

LLVA (Low Level Virtual Architecture) supports arbitrary languages including C, and enables sophisticated analyses and optimizations. It provides computational, memory access, and control flow operations.

However, LLVA “lacks operations a kernel needs to configure hardware behavior and manipulate program state”. Thus comes LLVA-OS.

LLVA-OS is a set of extensions to LLVA that provides an interface between the OS kernel and a general purpose processor architecture.

Two similar set of abstraction layers:

  • Application -> libc -> operating system/hardware

  • OS Kernel -> LLVA-OS -> hardware

OS-hardware Interfaces

Two types:

  • access specialized and privileged hardware components.

    • registering interrupt handlers;
    • configuring the MMU;
    • performing I/O.
  • manipulate the state of itself and other programs.

    • context switching;
    • signal delivery;
    • process createion.

Program states

virtual states

Virtual state is the system state as seen by external software, including the OS. The virtual state of an LLVA program includes:

  • The set of all virtual registers for all currently active function activations (?).
  • The implicit program counter indicating which virtual instruction to execute next.
  • The contents of memory used by the current program.
  • The current stack pointer indicating the bottom of the currently active stack.
  • The current privilege mode of the processor (either privileged or unprivileged).
  • A set of MMU control registers.
  • A local interrupt enable/disable flag.

native states

Native state is the state of the underlying physical processor and includes any processor state used by a translated program, such as

  • general purpose, floating point, and control flow registers.
  • coprocessors, such as MMUs, FPUs.

Overhead caused by the abstraction

Our evaluation revealed where our design choices added virtualization overhead to the Linux kernel: context switching, data copies between user and kernel memory, read page faults, and signal handler dispatch.

Applications of LLVA-OS

Memory safety for kernel

SVA-OS.

Kernel portability improvement

If LLVA-OS is able to support a large amount of architectures. Then the same kernel code would be able to run all the architectures without any modification.

Just like an unmodified java application runs on JVM on any architecture that could run JVM, an unmodified operating system will run on LLVA-OS on any architecture that are supported by LLVA-OS.

? Any related work. No. Here we see that advancement gap between application research and os research.

OS compatability of LLVA-OS

Different kernels would be able to be supported by the LLVA-OS interfaces.

Just like C, Java, and Rust can all be compiled to LLVM IR, and do optimization or security analysis in LLVM IR level, different OS kernels should also be able to be ‘compiled’ to the LLVA with LLVA-OS, enabling ‘IR level’ compiler analysis.

? Any related work. No. What is the core challenge here?

A compiler with full kernel knowledge, just like considering a kernel as a new language but contains the special instructions buried anywhere in any forms. How to compile this much messed language?


  1. A virtual instruction set interface for operating system kernels, WIOSCA, 2006. ↩
  2. LLVA: A Low-level Virtual Instruction Set Architecture. MICRO, 2003. ↩
Created Jul 5, 2019 // Last Updated Aug 31, 2020

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

... what would you change?