Kicking the Firmware Out of the TCB with the MIRALIS Virtual Firmware Monitor

Authors: C Castes, N. Kalani, S. Saltovskaia, N. Terrier, A. Wilkinson, E. Bugnion -- EPFL

Charly Castes, Neelu S. Kalani, Sofia Saltovskaia, Noé Terrier, Abel Vexina Wilkinson, and Edouard Bugnion. 2024. Kicking the Firmware Out of the TCB with the Miralis Virtual Firmware Monitor. In 2nd Workshop on Kernel Isolation, Safety and Verification (KISV ’24), November 4–6, 2024, Austin, TX, USA. ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/3698576.3698764

TL;DR

What? The paper introduces virtual firmware monitors (VFM), a design that deprivileges and isolates the non-security critical part of firmware in a virtual machine and keeps only a small, security-critical monitor in the trusted computing base (TCB).

Why? Firmware runs with the most privileges on the platform and is therefore part of the TCB of all other layers (i.e., hypervisor, kernel, user space), yet its non-security critical code has repeatedly been targeted by successful attacks. The goal is to reduce the amount of inherently trusted code without breaking compatibility or impacting performance.

How? The authors introduce MIRALIS, a VFM that virtualizes the monitor mode, deprivileges guest firmware, and keeps the security-critical functions under the control of a small VFM. They implement and evaluate it on RISC-V, showing that unmodified firmware and OSes can run with negligible performance impact.

Definitions

Firmware: Here, the term 'firmware' collectively designates the low-level software (1) that boots, initializes, and manages the platform's hardware (traditional firmware), and (2) that manages secure contexts for confidential computing applications, commonly referred to as the secure monitor. The firmware is the most privileged piece of software running on the platform: on Arm64 ISA, it usually runs in EL3, while on RISC-V, it runs in M-mode.

Virtualization: Virtualization, as formally defined by Popek and Goldberg in 1974, is a concept that provides strong isolation, equivalence (of the actual hardware and its virtualized interface), and close to native performance. A (classically) virtualizable instruction set architecture (ISA) is one for which all sensitive instructions are privileged, as the opposite could, e.g., lead to sandbox escape, violating the principle of strong isolation. Armv8-A and RISC-V are known examples of classically virtualizable ISAs.

Context

The firmware acts as the software root of trust for the device and plays a crucial role in confidential computing (secure monitor). It runs at the highest level of privilege on the platform and forms the foundation of the trusted computing base (TCB) of the entire software stack running on the system. Yet, its non-security critical part (outside the secure monitor) has repeatedly been the target of successful attacks (breached root of trust, arbitrary code execution, vulnerabilities in a driver allowing data erasure at a large scale, and many others), providing the attacker with complete control over the system and, therefore, breaking all security assumptions on the breached platform.

This paper proposes an alternative design, backward compatible with current firmware implementations, in which the non-security critical section is isolated and constrained in a virtual machine. The authors do so by introducing a "simple and verifiable virtual firmware monitor", effectively removing it from the TCB.

In this context, the authors present Miralis, a virtual firmware monitor, and demonstrate how its introduction removes vendor-provided, platform-specific firmware code from the TCB, with no impact on boot and runtime performance.

Design

The paper proposes a new class of systems called virtual firmware monitors (VFM). The authors place the virtualization boundary right below the monitor mode, i.e., between M-mode and S-mode on RISC-V, or between EL3 and EL2/EL1 on Arm (depending on whether the platform implements EL2). As such, VFMs virtualize the monitor mode, which can broadly be described as the set of the most privileged instructions of the platform. It is important to note that they do not aim to virtualize a larger set of instructions, allowing hypervisors and kernels to run bare-metal at native speed -- affecting only firmware performance.

Threat Model

A secure implementation of the VFM only needs to trust the correct implementation of the underlying hardware. Virtualization guarantees that guest firmware, i.e., virtualized firmware managed by the VFM, cannot breach the security of the host firmware, i.e., the virtual firmware manager. Furthermore, the VFM's attack surface is reduced by construction, given that its purpose is to deprivilege non-security critical code, therefore removing an otherwise equally privileged and often large code base. We also note that, although an additional hypervisor and kernels would potentially run bare-metal, the hardware already isolates such untrusted software from the firmware, as they run at their own isolated privilege level. Finally, the VFM ensures proper isolation between mutually distrusting guest firmware and OS.

Physical vectors such as side-channel, transient-execution attacks, and CPU bugs are left out of scope.

Implementation

Although maybe of lesser interest to the general reader as tightly coupled with RISC-V specifics, we go over some of the implementation details presented in the paper.

To validate the functionality of the design, the authors implement the MIRALIS VFM on a RISC-V platform. MIRALIS runs in M-mode and exposes a virtualized M-mode (referred to as vM-mode in the paper), allowing untrusted software to execute without the possibility of compromising the VFM.

MIRALIS presents two execution modes to the underlying software, namely vM-mode for guest firmware, and direct execution for hypervisor/OS and their applications, which the authors refer to as worlds.

Firmware running in vM-mode can trigger a transition to S- or U-mode. On the other hand, when the OS traps into M-mode (following e.g., a monitor call), the VFM automatically switches to vM-mode and forwards the request to let the guest firmware handle it. As such, MIRALIS does not need to implement any firmware functionality other than its security-critical function.

MIRALIS runs guest firmware in U-mode, which is a requirement in RISC-V, as running in S-mode would give unsupervised access to sensitive instructions (here, updating MMU configuration), which would allow behaviors contradicting Popek and Goldberg's criterion of equivalence. Indeed, on RISC-V, software running in M-mode always operates on physical addresses. Such firmware would therefore expect to be able to set up the memory management unit (MMU), but not to be affected by it. A deprivileged firmware running in S-mode will be able to set up memory translation, and will be affected by it. We note that running guest firmware with higher privileges has the potential to show better performance, as fewer instructions will need to be trapped and emulated.

The authors claim that emulation of privileged instructions is relatively simple, as there are few on RISC-V. However, emulation of control and status registers (CSRs) is more complicated due to their number (over a hundred). At the time of publishing, MIRALIS supports 49 CSRs, covering the needs of Linux, Zephyr, and OpenSBI.

All the S-mode CSRs, as well as most M-mode CSRs can be directly installed into their physical equivalent when switching from vM-mode to S-mode. Some, however, such as PMP registers, need to stay under the control of the VFM. On RISC-V, physical memory protection (PMP) registers are an optional set of ordered registers allowing M-mode to configure access permissions to contiguous physical memory regions. They are ordered in the sense that the first entry to match a physical memory carve-out will determine the access rules for that segment -- think of it as firewall rules. PMPs are the backbone of confidential computing on RISC-V platforms. For the sake of comparing architectures, their role can be loosely described as equivalent to that of TrustZone address space controllers on Armv8-A, or granule protection tables on Armv9-A.

When switching worlds from S-mode to vM-mode, MIRALIS installs the physical CSRs (potentially updated by the kernel) into their virtual equivalent before forwarding control to the virtual firmware. Since the PMP registers are limited in number, the VFM carefully configures and shares them between itself, i.e., the host firmware, and the guest firmware.

Evaluation

For security reasons, it is important that the VFM can be open-sourced (e.g., for third-party verification) and is small enough to be formally verified. Since it (1) only exposes a well-defined interface, and (2) delegates all proprietary hardware management functionality to the guest firmware and only takes care of generic (to the ISA) security enforcement services, e.g., security state and context management during world switches, MIRALIS has a small footprint (the authors report 3392 lines of code in total) simplifying its formal verification. Furthermore, since it is decoupled from IP hardware management, it can be open-sourced.

In the paper, the authors propose a method to formally verify the correctness of privileged instructions and trap emulation in VFMs automatically.

To demonstrate the feasability of their design, the authors implement MIRALIS on QEMU for development and on a VisionFive2 board for a real-hardware demonstrator. They evaluate the feasability of running unmodified firmware and OS on top of a VFM with two setups,

1. by running OpenSBI in vM-mode, alongside a stock Linux kernel in S-mode, and
2. by running ZephyrRTOS (much richer set of features than OpenSBI) in vM-mode.

We note that the evaluation on the VisionFive2 board also allows to evaluate the integration of MIRALIS in a non-trivial boot process, depicted on the picture below (Figure 5) with performance results attached (Table 3 and 4).

Note on current limitations: At the time of publishing, MIRALIS did not yet support full initialization of Linux. Furthermore, it does not support multi-core, which might prove limiting in some cases.

Conclusion

The paper introduces the concept of virtual firmware monitors (VFM). This new architecture decouples the Firmware in (1) a security critical part, residing at the highest level of privilege on the platform, and (2) a non-security critical split called (traditional) firmware, implementing the historical functionality of firmware which is booting, initializing, and managing the hardware of the platform, now virtualized and deprivileged to userland.

This model removes the firmware from the TCB, keeping only security-critical components running in the most privileged mode, allowing it to be open-sourced (since it is now free of proprietary hardware management) and formally verifiable, while maintaining backward-compatibility.

The authors implement MIRALIS, a VFM implemented in Rust on RISC-V and evaluate it. Evaluation shows feasibility of running unmodified deprivileged firmware in a virtualized M-mode (vM-mode) alongside unmodified OSes in S-mode with a negligible impact on performance.