Hello, world!
I am glad to announce that today we open-sourced Miralis, a project I have been working on for the last six months together with some awesome people! We are still in the very early days, but I think we already built something quite interesting, and I am looking forward to continue developing Miralis in the open.
The Achilles' heel of the compute infrastructure
The Miralis project started from the realisation that modern computers are built on top of two incompatible assumptions at the lowest level of the stack: the computer's firmware. On one hand the firmware's responsibility is to manage and configure the hardware, it is often proprietary and presented as an opaque binary blob that needs to be installed on all machines. On the other hand, the firmware recently gained a new role as the entity that enforces machine-wide security policies. This is especially true with the rise of confidential computing (e.g. ARM CCA or RISC-V's Keystone), where the responsibility to provide isolation is shifted from the OS/hypervisor to the firmware.
The two roles of the firmware, managing the hardware and enforcing security policies, are fundamentally in tension with each other, or at least will be until hardware manufacturers agree to release the source of their firmware. Until then, the security of the world's compute infrastructure has no choice but to rely on opaque binary blobs.
With Miralis we would like to propose something different. We acknowledge the need for proprietary firmware but we do not want to rely on it for security. Rather, we propose to deprivilege proprietary firmware and to enforce strong isolation policies to decouple the security of the rest of the computing stack from the correctness (and cooperation) of opaque firmware. We understand that requiring firmware changes would be disruptive, therefore we propose to execute unmodified firmware by virtualising and sandboxing the lowest privilege level on the machine.
Miralis in a nutshell
In short Miralis is RISC-V security monitor that virtualises M-mode software. By "virtualise M-mode software" I mean that Miralis can run deprivileged M-mode software transparently, like it would execute on a bare metal RISC-V machine. As a quick summary for people new to RISC-V, the RISC-V architecture exposes up to three privilege modes (ignoring the hypervisor extension): user mode (U-mode, for applications), supervisor mode (S-mode, for the OS kernel), and machine mode (M-mode, for the firmware).
┌──────────────┐
U-mode │ User App │
├──────────────┤
S-mode │ OS │
├──────────────┤
M-mode │ Firmware │
└──────────────┘
With Miralis we make it possible to execute firmware in a virtual M-mode. In practice we run the firmware in U-mode under the control of Miralis. This makes it possible to sandbox M-mode software, which how we protect the rest of the stack from untrusted firmware, while running the OS natively at full speed.
┌──────────────┐ ┌────────────┐
U-mode │ User App │ │ Firmware │
├──────────────┤ └────────────┘
S-mode │ OS │
├──────────────┴──────────────┐
M-mode │ Miralis │
└─────────────────────────────┘
The firmware is virtualised using a classical trap & emulate approach: most of the instructions are executed natively by the processor, but privileged instructions trap to Miralis which will emulate them in software (while enforcing security invariants).
Current status
The project started six months ago, slowly at first but we are now making progress at a steady pace. The initial focus was on the software architecture, to make the project modular and as future proof as we could anticipate. The main components of Miralis are in place. This include for instance the instruction decoder, instruction emulation, virtual contexts, and context switching. The code base is modular over the platform (to support multiple boards and SoCs in the future) and the architecture (to support, e.g., running Miralis in user-space for unit and integration testing).
We do not yet support a wide variety of workloads, but we do have a solid foundation. Miralis can already boot an unmodified OpenSBI in virtual M-mode (that is physical U-mode) with a simple payload. We also experimented with other firmware, such as Zephyr for which we have early support.
I would like use this opportunity to thank all the people who contributed to the Miralis project, especially my awesome colleague Neelu who helped design Miralis, Abel who achieved a tremendous amount of work over the last semester and actually took Miralis to the place it is today, and François who recently joined the effort and made some great contributions.
What is next
This summer we will focus on delivering on the Miralis promises, in particular by focusing on full Linux support and porting Miralis to physical boards in addition to our current QEMU support. We will also explore new approaches to deliver best-in-class security, in particular through an innovative take a formally verifying crucial pieces of Miralis, a subject I would like to discuss more in the near future.
Over the summer Sofia and Noé will be joining forces, I'm sure we will be able to achieve a lot by working together and I am looking forward to see how far we can go with Miralis, with the ultimate goal to help secure the foundations of the world's compute infrastructure.