Documentation/security/snp-tdx-threat-model.rst

   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