Commit | Line | Data |
---|---|---|
1f597b1a CB |
1 | ====================================================== |
2 | Confidential Computing in Linux for x86 virtualization | |
3 | ====================================================== | |
4 | ||
5 | .. contents:: :local: | |
6 | ||
7 | By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao@amd.com> | |
8 | ||
9 | Motivation | |
10 | ========== | |
11 | ||
12 | Kernel developers working on confidential computing for virtualized | |
13 | environments in x86 operate under a set of assumptions regarding the Linux | |
14 | kernel threat model that differ from the traditional view. Historically, | |
15 | the Linux threat model acknowledges attackers residing in userspace, as | |
16 | well as a limited set of external attackers that are able to interact with | |
17 | the kernel through various networking or limited HW-specific exposed | |
18 | interfaces (USB, thunderbolt). The goal of this document is to explain | |
19 | additional attack vectors that arise in the confidential computing space | |
20 | and discuss the proposed protection mechanisms for the Linux kernel. | |
21 | ||
22 | Overview and terminology | |
23 | ======================== | |
24 | ||
25 | Confidential Computing (CoCo) is a broad term covering a wide range of | |
26 | security technologies that aim to protect the confidentiality and integrity | |
27 | of data in use (vs. data at rest or data in transit). At its core, CoCo | |
28 | solutions provide a Trusted Execution Environment (TEE), where secure data | |
29 | processing can be performed and, as a result, they are typically further | |
30 | classified into different subtypes depending on the SW that is intended | |
31 | to be run in TEE. This document focuses on a subclass of CoCo technologies | |
32 | that are targeting virtualized environments and allow running Virtual | |
33 | Machines (VM) inside TEE. From now on in this document will be referring | |
34 | to this subclass of CoCo as 'Confidential Computing (CoCo) for the | |
35 | virtualized environments (VE)'. | |
36 | ||
37 | CoCo, in the virtualization context, refers to a set of HW and/or SW | |
38 | technologies that allow for stronger security guarantees for the SW running | |
39 | inside a CoCo VM. Namely, confidential computing allows its users to | |
40 | confirm the trustworthiness of all SW pieces to include in its reduced | |
41 | Trusted Computing Base (TCB) given its ability to attest the state of these | |
42 | trusted components. | |
43 | ||
44 | While the concrete implementation details differ between technologies, all | |
45 | available mechanisms aim to provide increased confidentiality and | |
46 | integrity for the VM's guest memory and execution state (vCPU registers), | |
47 | more tightly controlled guest interrupt injection, as well as some | |
48 | additional mechanisms to control guest-host page mapping. More details on | |
49 | the 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 | ||
53 | The basic CoCo guest layout includes the host, guest, the interfaces that | |
54 | communicate guest and host, a platform capable of supporting CoCo VMs, and | |
55 | a trusted intermediary between the guest VM and the underlying platform | |
56 | that acts as a security manager. The host-side virtual machine monitor | |
57 | (VMM) typically consists of a subset of traditional VMM features and | |
58 | is still in charge of the guest lifecycle, i.e. create or destroy a CoCo | |
59 | VM, manage its access to system resources, etc. However, since it | |
60 | typically stays out of CoCo VM TCB, its access is limited to preserve the | |
61 | security objectives. | |
62 | ||
63 | In the following diagram, the "<--->" lines represent bi-directional | |
64 | communication channels or interfaces between the CoCo security manager and | |
65 | the 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 | ||
79 | The specific details of the CoCo security manager vastly diverge between | |
80 | technologies. For example, in some cases, it will be implemented in HW | |
81 | while in others it may be pure SW. | |
82 | ||
83 | Existing Linux kernel threat model | |
84 | ================================== | |
85 | ||
86 | The 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 | ||
102 | There is also communication between the bootloader and the kernel during | |
103 | the boot process, but this diagram does not represent it explicitly. The | |
104 | "Interfaces" box represents the various interfaces that allow | |
105 | communication between kernel and userspace. This includes system calls, | |
106 | kernel APIs, device drivers, etc. | |
107 | ||
108 | The existing Linux kernel threat model typically assumes execution on a | |
109 | trusted HW platform with all of the firmware and bootloaders included on | |
110 | its TCB. The primary attacker resides in the userspace, and all of the data | |
111 | coming from there is generally considered untrusted, unless userspace is | |
112 | privileged enough to perform trusted actions. In addition, external | |
113 | attackers are typically considered, including those with access to enabled | |
114 | external networks (e.g. Ethernet, Wireless, Bluetooth), exposed hardware | |
115 | interfaces (e.g. USB, Thunderbolt), and the ability to modify the contents | |
116 | of disks offline. | |
117 | ||
118 | Regarding external attack vectors, it is interesting to note that in most | |
119 | cases external attackers will try to exploit vulnerabilities in userspace | |
120 | first, but that it is possible for an attacker to directly target the | |
121 | kernel; particularly if the host has physical access. Examples of direct | |
122 | kernel attacks include the vulnerabilities CVE-2019-19524, CVE-2022-0435 | |
123 | and CVE-2020-24490. | |
124 | ||
125 | Confidential Computing threat model and its security objectives | |
126 | =============================================================== | |
127 | ||
128 | Confidential Computing adds a new type of attacker to the above list: a | |
129 | potentially misbehaving host (which can also include some part of a | |
130 | traditional VMM or all of it), which is typically placed outside of the | |
131 | CoCo VM TCB due to its large SW attack surface. It is important to note | |
132 | that this doesn’t imply that the host or VMM are intentionally | |
133 | malicious, but that there exists a security value in having a small CoCo | |
134 | VM TCB. This new type of adversary may be viewed as a more powerful type | |
135 | of 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 | |
137 | kernel 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 | ||
160 | While traditionally the host has unlimited access to guest data and can | |
161 | leverage this access to attack the guest, the CoCo systems mitigate such | |
162 | attacks by adding security features like guest data confidentiality and | |
163 | integrity protection. This threat model assumes that those features are | |
164 | available and intact. | |
165 | ||
166 | The **Linux kernel CoCo VM security objectives** can be summarized as follows: | |
167 | ||
168 | 1. Preserve the confidentiality and integrity of CoCo guest's private | |
169 | memory and registers. | |
170 | ||
171 | 2. Prevent privileged escalation from a host into a CoCo guest Linux kernel. | |
172 | While it is true that the host (and host-side VMM) requires some level of | |
173 | privilege to create, destroy, or pause the guest, part of the goal of | |
174 | preventing privileged escalation is to ensure that these operations do not | |
175 | provide a pathway for attackers to gain access to the guest's kernel. | |
176 | ||
177 | The above security objectives result in two primary **Linux kernel CoCo | |
178 | VM assets**: | |
179 | ||
180 | 1. Guest kernel execution context. | |
181 | 2. Guest kernel private memory. | |
182 | ||
183 | The host retains full control over the CoCo guest resources, and can deny | |
184 | access to them at any time. Examples of resources include CPU time, memory | |
185 | that the guest can consume, network bandwidth, etc. Because of this, the | |
186 | host Denial of Service (DoS) attacks against CoCo guests are beyond the | |
187 | scope of this threat model. | |
188 | ||
189 | The **Linux CoCo VM attack surface** is any interface exposed from a CoCo | |
190 | guest Linux kernel towards an untrusted host that is not covered by the | |
191 | CoCo technology SW/HW protection. This includes any possible | |
192 | side-channels, as well as transient execution side channels. Examples of | |
193 | explicit (not side-channel) interfaces include accesses to port I/O, MMIO | |
194 | and DMA interfaces, access to PCI configuration space, VMM-specific | |
195 | hypercalls (towards Host-side VMM), access to shared memory pages, | |
196 | interrupts allowed to be injected into the guest kernel by the host, as | |
197 | well as CoCo technology-specific hypercalls, if present. Additionally, the | |
198 | host in a CoCo system typically controls the process of creating a CoCo | |
199 | guest: it has a method to load into a guest the firmware and bootloader | |
200 | images, the kernel image together with the kernel command line. All of this | |
201 | data should also be considered untrusted until its integrity and | |
202 | authenticity is established via attestation. | |
203 | ||
204 | The table below shows a threat matrix for the CoCo guest Linux kernel but | |
205 | does not discuss potential mitigation strategies. The matrix refers to | |
206 | CoCo-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 |