| ====================================================== |
| Confidential Computing in Linux for x86 virtualization |
| ====================================================== |
| |
| .. contents:: :local: |
| |
| By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao.osdev@gmail.com> |
| |
| Motivation |
| ========== |
| |
| Kernel developers working on confidential computing for virtualized |
| environments in x86 operate under a set of assumptions regarding the Linux |
| kernel threat model that differ from the traditional view. Historically, |
| the Linux threat model acknowledges attackers residing in userspace, as |
| well as a limited set of external attackers that are able to interact with |
| the kernel through various networking or limited HW-specific exposed |
| interfaces (USB, thunderbolt). The goal of this document is to explain |
| additional attack vectors that arise in the confidential computing space |
| and discuss the proposed protection mechanisms for the Linux kernel. |
| |
| Overview and terminology |
| ======================== |
| |
| Confidential Computing (CoCo) is a broad term covering a wide range of |
| security technologies that aim to protect the confidentiality and integrity |
| of data in use (vs. data at rest or data in transit). At its core, CoCo |
| solutions provide a Trusted Execution Environment (TEE), where secure data |
| processing can be performed and, as a result, they are typically further |
| classified into different subtypes depending on the SW that is intended |
| to be run in TEE. This document focuses on a subclass of CoCo technologies |
| that are targeting virtualized environments and allow running Virtual |
| Machines (VM) inside TEE. From now on in this document will be referring |
| to this subclass of CoCo as 'Confidential Computing (CoCo) for the |
| virtualized environments (VE)'. |
| |
| CoCo, in the virtualization context, refers to a set of HW and/or SW |
| technologies that allow for stronger security guarantees for the SW running |
| inside a CoCo VM. Namely, confidential computing allows its users to |
| confirm the trustworthiness of all SW pieces to include in its reduced |
| Trusted Computing Base (TCB) given its ability to attest the state of these |
| trusted components. |
| |
| While the concrete implementation details differ between technologies, all |
| available mechanisms aim to provide increased confidentiality and |
| integrity for the VM's guest memory and execution state (vCPU registers), |
| more tightly controlled guest interrupt injection, as well as some |
| additional mechanisms to control guest-host page mapping. More details on |
| the x86-specific solutions can be found in |
| :doc:`Intel Trust Domain Extensions (TDX) </arch/x86/tdx>` and |
| `AMD Memory Encryption <https://www.amd.com/system/files/techdocs/sev-snp-strengthening-vm-isolation-with-integrity-protection-and-more.pdf>`_. |
| |
| The basic CoCo guest layout includes the host, guest, the interfaces that |
| communicate guest and host, a platform capable of supporting CoCo VMs, and |
| a trusted intermediary between the guest VM and the underlying platform |
| that acts as a security manager. The host-side virtual machine monitor |
| (VMM) typically consists of a subset of traditional VMM features and |
| is still in charge of the guest lifecycle, i.e. create or destroy a CoCo |
| VM, manage its access to system resources, etc. However, since it |
| typically stays out of CoCo VM TCB, its access is limited to preserve the |
| security objectives. |
| |
| In the following diagram, the "<--->" lines represent bi-directional |
| communication channels or interfaces between the CoCo security manager and |
| the rest of the components (data flow for guest, host, hardware) :: |
| |
| +-------------------+ +-----------------------+ |
| | CoCo guest VM |<---->| | |
| +-------------------+ | | |
| | Interfaces | | CoCo security manager | |
| +-------------------+ | | |
| | Host VMM |<---->| | |
| +-------------------+ | | |
| | | |
| +--------------------+ | | |
| | CoCo platform |<--->| | |
| +--------------------+ +-----------------------+ |
| |
| The specific details of the CoCo security manager vastly diverge between |
| technologies. For example, in some cases, it will be implemented in HW |
| while in others it may be pure SW. |
| |
| Existing Linux kernel threat model |
| ================================== |
| |
| The overall components of the current Linux kernel threat model are:: |
| |
| +-----------------------+ +-------------------+ |
| | |<---->| Userspace | |
| | | +-------------------+ |
| | External attack | | Interfaces | |
| | vectors | +-------------------+ |
| | |<---->| Linux Kernel | |
| | | +-------------------+ |
| +-----------------------+ +-------------------+ |
| | Bootloader/BIOS | |
| +-------------------+ |
| +-------------------+ |
| | HW platform | |
| +-------------------+ |
| |
| There is also communication between the bootloader and the kernel during |
| the boot process, but this diagram does not represent it explicitly. The |
| "Interfaces" box represents the various interfaces that allow |
| communication between kernel and userspace. This includes system calls, |
| kernel APIs, device drivers, etc. |
| |
| The existing Linux kernel threat model typically assumes execution on a |
| trusted HW platform with all of the firmware and bootloaders included on |
| its TCB. The primary attacker resides in the userspace, and all of the data |
| coming from there is generally considered untrusted, unless userspace is |
| privileged enough to perform trusted actions. In addition, external |
| attackers are typically considered, including those with access to enabled |
| external networks (e.g. Ethernet, Wireless, Bluetooth), exposed hardware |
| interfaces (e.g. USB, Thunderbolt), and the ability to modify the contents |
| of disks offline. |
| |
| Regarding external attack vectors, it is interesting to note that in most |
| cases external attackers will try to exploit vulnerabilities in userspace |
| first, but that it is possible for an attacker to directly target the |
| kernel; particularly if the host has physical access. Examples of direct |
| kernel attacks include the vulnerabilities CVE-2019-19524, CVE-2022-0435 |
| and CVE-2020-24490. |
| |
| Confidential Computing threat model and its security objectives |
| =============================================================== |
| |
| Confidential Computing adds a new type of attacker to the above list: a |
| potentially misbehaving host (which can also include some part of a |
| traditional VMM or all of it), which is typically placed outside of the |
| CoCo VM TCB due to its large SW attack surface. It is important to note |
| that this doesn’t imply that the host or VMM are intentionally |
| malicious, but that there exists a security value in having a small CoCo |
| VM TCB. This new type of adversary may be viewed as a more powerful type |
| of external attacker, as it resides locally on the same physical machine |
| (in contrast to a remote network attacker) and has control over the guest |
| kernel communication with most of the HW:: |
| |
| +------------------------+ |
| | CoCo guest VM | |
| +-----------------------+ | +-------------------+ | |
| | |<--->| | Userspace | | |
| | | | +-------------------+ | |
| | External attack | | | Interfaces | | |
| | vectors | | +-------------------+ | |
| | |<--->| | Linux Kernel | | |
| | | | +-------------------+ | |
| +-----------------------+ | +-------------------+ | |
| | | Bootloader/BIOS | | |
| +-----------------------+ | +-------------------+ | |
| | |<--->+------------------------+ |
| | | | Interfaces | |
| | | +------------------------+ |
| | CoCo security |<--->| Host/Host-side VMM | |
| | manager | +------------------------+ |
| | | +------------------------+ |
| | |<--->| CoCo platform | |
| +-----------------------+ +------------------------+ |
| |
| While traditionally the host has unlimited access to guest data and can |
| leverage this access to attack the guest, the CoCo systems mitigate such |
| attacks by adding security features like guest data confidentiality and |
| integrity protection. This threat model assumes that those features are |
| available and intact. |
| |
| The **Linux kernel CoCo VM security objectives** can be summarized as follows: |
| |
| 1. Preserve the confidentiality and integrity of CoCo guest's private |
| memory and registers. |
| |
| 2. Prevent privileged escalation from a host into a CoCo guest Linux kernel. |
| While it is true that the host (and host-side VMM) requires some level of |
| privilege to create, destroy, or pause the guest, part of the goal of |
| preventing privileged escalation is to ensure that these operations do not |
| provide a pathway for attackers to gain access to the guest's kernel. |
| |
| The above security objectives result in two primary **Linux kernel CoCo |
| VM assets**: |
| |
| 1. Guest kernel execution context. |
| 2. Guest kernel private memory. |
| |
| The host retains full control over the CoCo guest resources, and can deny |
| access to them at any time. Examples of resources include CPU time, memory |
| that the guest can consume, network bandwidth, etc. Because of this, the |
| host Denial of Service (DoS) attacks against CoCo guests are beyond the |
| scope of this threat model. |
| |
| The **Linux CoCo VM attack surface** is any interface exposed from a CoCo |
| guest Linux kernel towards an untrusted host that is not covered by the |
| CoCo technology SW/HW protection. This includes any possible |
| side-channels, as well as transient execution side channels. Examples of |
| explicit (not side-channel) interfaces include accesses to port I/O, MMIO |
| and DMA interfaces, access to PCI configuration space, VMM-specific |
| hypercalls (towards Host-side VMM), access to shared memory pages, |
| interrupts allowed to be injected into the guest kernel by the host, as |
| well as CoCo technology-specific hypercalls, if present. Additionally, the |
| host in a CoCo system typically controls the process of creating a CoCo |
| guest: it has a method to load into a guest the firmware and bootloader |
| images, the kernel image together with the kernel command line. All of this |
| data should also be considered untrusted until its integrity and |
| authenticity is established via attestation. |
| |
| The table below shows a threat matrix for the CoCo guest Linux kernel but |
| does not discuss potential mitigation strategies. The matrix refers to |
| CoCo-specific versions of the guest, host and platform. |
| |
| .. list-table:: CoCo Linux guest kernel threat matrix |
| :widths: auto |
| :align: center |
| :header-rows: 1 |
| |
| * - Threat name |
| - Threat description |
| |
| * - Guest malicious configuration |
| - A misbehaving host modifies one of the following guest's |
| configuration: |
| |
| 1. Guest firmware or bootloader |
| |
| 2. Guest kernel or module binaries |
| |
| 3. Guest command line parameters |
| |
| This allows the host to break the integrity of the code running |
| inside a CoCo guest, and violates the CoCo security objectives. |
| |
| * - CoCo guest data attacks |
| - A misbehaving host retains full control of the CoCo guest's data |
| in-transit between the guest and the host-managed physical or |
| virtual devices. This allows any attack against confidentiality, |
| integrity or freshness of such data. |
| |
| * - Malformed runtime input |
| - A misbehaving host injects malformed input via any communication |
| interface used by the guest's kernel code. If the code is not |
| prepared to handle this input correctly, this can result in a host |
| --> guest kernel privilege escalation. This includes traditional |
| side-channel and/or transient execution attack vectors. |
| |
| * - Malicious runtime input |
| - A misbehaving host injects a specific input value via any |
| communication interface used by the guest's kernel code. The |
| difference with the previous attack vector (malformed runtime input) |
| is that this input is not malformed, but its value is crafted to |
| impact the guest's kernel security. Examples of such inputs include |
| providing a malicious time to the guest or the entropy to the guest |
| random number generator. Additionally, the timing of such events can |
| be an attack vector on its own, if it results in a particular guest |
| kernel action (i.e. processing of a host-injected interrupt). |
| resistant to supplied host input. |
| |
