1======================================================
2Confidential Computing in Linux for x86 virtualization
3======================================================
4
5.. contents:: :local:
6
7By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao@amd.com>
8
9Motivation
10==========
11
12Kernel developers working on confidential computing for virtualized
13environments in x86 operate under a set of assumptions regarding the Linux
14kernel threat model that differ from the traditional view. Historically,
15the Linux threat model acknowledges attackers residing in userspace, as
16well as a limited set of external attackers that are able to interact with
17the kernel through various networking or limited HW-specific exposed
18interfaces (USB, thunderbolt). The goal of this document is to explain
19additional attack vectors that arise in the confidential computing space
20and discuss the proposed protection mechanisms for the Linux kernel.
21
22Overview and terminology
23========================
24
25Confidential Computing (CoCo) is a broad term covering a wide range of
26security technologies that aim to protect the confidentiality and integrity
27of data in use (vs. data at rest or data in transit). At its core, CoCo
28solutions provide a Trusted Execution Environment (TEE), where secure data
29processing can be performed and, as a result, they are typically further
30classified into different subtypes depending on the SW that is intended
31to be run in TEE. This document focuses on a subclass of CoCo technologies
32that are targeting virtualized environments and allow running Virtual
33Machines (VM) inside TEE. From now on in this document will be referring
34to this subclass of CoCo as 'Confidential Computing (CoCo) for the
35virtualized environments (VE)'.
36
37CoCo, in the virtualization context, refers to a set of HW and/or SW
38technologies that allow for stronger security guarantees for the SW running
39inside a CoCo VM. Namely, confidential computing allows its users to
40confirm the trustworthiness of all SW pieces to include in its reduced
41Trusted Computing Base (TCB) given its ability to attest the state of these
42trusted components.
43
44While the concrete implementation details differ between technologies, all
45available mechanisms aim to provide increased confidentiality and
46integrity for the VM's guest memory and execution state (vCPU registers),
47more tightly controlled guest interrupt injection, as well as some
48additional mechanisms to control guest-host page mapping. More details on
49the x86-specific solutions can be found in
50:doc:`Intel Trust Domain Extensions (TDX) </arch/x86/tdx>` and
51`AMD Memory Encryption <https://www.amd.com/system/files/techdocs/sev-snp-strengthening-vm-isolation-with-integrity-protection-and-more.pdf>`_.
52
53The basic CoCo guest layout includes the host, guest, the interfaces that
54communicate guest and host, a platform capable of supporting CoCo VMs, and
55a trusted intermediary between the guest VM and the underlying platform
56that acts as a security manager. The host-side virtual machine monitor
57(VMM) typically consists of a subset of traditional VMM features and
58is still in charge of the guest lifecycle, i.e. create or destroy a CoCo
59VM, manage its access to system resources, etc. However, since it
60typically stays out of CoCo VM TCB, its access is limited to preserve the
61security objectives.
62
63In the following diagram, the "<--->" lines represent bi-directional
64communication channels or interfaces between the CoCo security manager and
65the rest of the components (data flow for guest, host, hardware) ::
66
67    +-------------------+      +-----------------------+
68    | CoCo guest VM     |<---->|                       |
69    +-------------------+      |                       |
70      | Interfaces |           | CoCo security manager |
71    +-------------------+      |                       |
72    | Host VMM          |<---->|                       |
73    +-------------------+      |                       |
74                               |                       |
75    +--------------------+     |                       |
76    | CoCo platform      |<--->|                       |
77    +--------------------+     +-----------------------+
78
79The specific details of the CoCo security manager vastly diverge between
80technologies. For example, in some cases, it will be implemented in HW
81while in others it may be pure SW.
82
83Existing Linux kernel threat model
84==================================
85
86The overall components of the current Linux kernel threat model are::
87
88     +-----------------------+      +-------------------+
89     |                       |<---->| Userspace         |
90     |                       |      +-------------------+
91     |   External attack     |         | Interfaces |
92     |       vectors         |      +-------------------+
93     |                       |<---->| Linux Kernel      |
94     |                       |      +-------------------+
95     +-----------------------+      +-------------------+
96                                    | Bootloader/BIOS   |
97                                    +-------------------+
98                                    +-------------------+
99                                    | HW platform       |
100                                    +-------------------+
101
102There is also communication between the bootloader and the kernel during
103the boot process, but this diagram does not represent it explicitly. The
104"Interfaces" box represents the various interfaces that allow
105communication between kernel and userspace. This includes system calls,
106kernel APIs, device drivers, etc.
107
108The existing Linux kernel threat model typically assumes execution on a
109trusted HW platform with all of the firmware and bootloaders included on
110its TCB. The primary attacker resides in the userspace, and all of the data
111coming from there is generally considered untrusted, unless userspace is
112privileged enough to perform trusted actions. In addition, external
113attackers are typically considered, including those with access to enabled
114external networks (e.g. Ethernet, Wireless, Bluetooth), exposed hardware
115interfaces (e.g. USB, Thunderbolt), and the ability to modify the contents
116of disks offline.
117
118Regarding external attack vectors, it is interesting to note that in most
119cases external attackers will try to exploit vulnerabilities in userspace
120first, but that it is possible for an attacker to directly target the
121kernel; particularly if the host has physical access. Examples of direct
122kernel attacks include the vulnerabilities CVE-2019-19524, CVE-2022-0435
123and CVE-2020-24490.
124
125Confidential Computing threat model and its security objectives
126===============================================================
127
128Confidential Computing adds a new type of attacker to the above list: a
129potentially misbehaving host (which can also include some part of a
130traditional VMM or all of it), which is typically placed outside of the
131CoCo VM TCB due to its large SW attack surface. It is important to note
132that this doesn���t imply that the host or VMM are intentionally
133malicious, but that there exists a security value in having a small CoCo
134VM TCB. This new type of adversary may be viewed as a more powerful type
135of external attacker, as it resides locally on the same physical machine
136(in contrast to a remote network attacker) and has control over the guest
137kernel communication with most of the HW::
138
139                                 +------------------------+
140                                 |    CoCo guest VM       |
141   +-----------------------+     |  +-------------------+ |
142   |                       |<--->|  | Userspace         | |
143   |                       |     |  +-------------------+ |
144   |   External attack     |     |     | Interfaces |     |
145   |       vectors         |     |  +-------------------+ |
146   |                       |<--->|  | Linux Kernel      | |
147   |                       |     |  +-------------------+ |
148   +-----------------------+     |  +-------------------+ |
149                                 |  | Bootloader/BIOS   | |
150   +-----------------------+     |  +-------------------+ |
151   |                       |<--->+------------------------+
152   |                       |          | Interfaces |
153   |                       |     +------------------------+
154   |     CoCo security     |<--->| Host/Host-side VMM |
155   |      manager          |     +------------------------+
156   |                       |     +------------------------+
157   |                       |<--->|   CoCo platform        |
158   +-----------------------+     +------------------------+
159
160While traditionally the host has unlimited access to guest data and can
161leverage this access to attack the guest, the CoCo systems mitigate such
162attacks by adding security features like guest data confidentiality and
163integrity protection. This threat model assumes that those features are
164available and intact.
165
166The **Linux kernel CoCo VM security objectives** can be summarized as follows:
167
1681. Preserve the confidentiality and integrity of CoCo guest's private
169memory and registers.
170
1712. Prevent privileged escalation from a host into a CoCo guest Linux kernel.
172While it is true that the host (and host-side VMM) requires some level of
173privilege to create, destroy, or pause the guest, part of the goal of
174preventing privileged escalation is to ensure that these operations do not
175provide a pathway for attackers to gain access to the guest's kernel.
176
177The above security objectives result in two primary **Linux kernel CoCo
178VM assets**:
179
1801. Guest kernel execution context.
1812. Guest kernel private memory.
182
183The host retains full control over the CoCo guest resources, and can deny
184access to them at any time. Examples of resources include CPU time, memory
185that the guest can consume, network bandwidth, etc. Because of this, the
186host Denial of Service (DoS) attacks against CoCo guests are beyond the
187scope of this threat model.
188
189The **Linux CoCo VM attack surface** is any interface exposed from a CoCo
190guest Linux kernel towards an untrusted host that is not covered by the
191CoCo technology SW/HW protection. This includes any possible
192side-channels, as well as transient execution side channels. Examples of
193explicit (not side-channel) interfaces include accesses to port I/O, MMIO
194and DMA interfaces, access to PCI configuration space, VMM-specific
195hypercalls (towards Host-side VMM), access to shared memory pages,
196interrupts allowed to be injected into the guest kernel by the host, as
197well as CoCo technology-specific hypercalls, if present. Additionally, the
198host in a CoCo system typically controls the process of creating a CoCo
199guest: it has a method to load into a guest the firmware and bootloader
200images, the kernel image together with the kernel command line. All of this
201data should also be considered untrusted until its integrity and
202authenticity is established via attestation.
203
204The table below shows a threat matrix for the CoCo guest Linux kernel but
205does not discuss potential mitigation strategies. The matrix refers to
206CoCo-specific versions of the guest, host and platform.
207
208.. list-table:: CoCo Linux guest kernel threat matrix
209   :widths: auto
210   :align: center
211   :header-rows: 1
212
213   * - Threat name
214     - Threat description
215
216   * - Guest malicious configuration
217     - A misbehaving host modifies one of the following guest's
218       configuration:
219
220       1. Guest firmware or bootloader
221
222       2. Guest kernel or module binaries
223
224       3. Guest command line parameters
225
226       This allows the host to break the integrity of the code running
227       inside a CoCo guest, and violates the CoCo security objectives.
228
229   * - CoCo guest data attacks
230     - A misbehaving host retains full control of the CoCo guest's data
231       in-transit between the guest and the host-managed physical or
232       virtual devices. This allows any attack against confidentiality,
233       integrity or freshness of such data.
234
235   * - Malformed runtime input
236     - A misbehaving host injects malformed input via any communication
237       interface used by the guest's kernel code. If the code is not
238       prepared to handle this input correctly, this can result in a host
239       --> guest kernel privilege escalation. This includes traditional
240       side-channel and/or transient execution attack vectors.
241
242   * - Malicious runtime input
243     - A misbehaving host injects a specific input value via any
244       communication interface used by the guest's kernel code. The
245       difference with the previous attack vector (malformed runtime input)
246       is that this input is not malformed, but its value is crafted to
247       impact the guest's kernel security. Examples of such inputs include
248       providing a malicious time to the guest or the entropy to the guest
249       random number generator. Additionally, the timing of such events can
250       be an attack vector on its own, if it results in a particular guest
251       kernel action (i.e. processing of a host-injected interrupt).
252       resistant to supplied host input.
253
254