Message-ID: <20230327141816.2648615-1-carlos.bilbao@amd.com>
Date:   Mon, 27 Mar 2023 09:18:16 -0500
From:   Carlos Bilbao <carlos.bilbao@....com>
To:     <corbet@....net>
CC:     <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <ardb@...nel.org>, <kraxel@...hat.com>, <dovmurik@...ux.ibm.com>,
        <elena.reshetova@...el.com>, <dave.hansen@...ux.intel.com>,
        <Dhaval.Giani@....com>, <michael.day@....com>,
        <pavankumar.paluri@....com>, <David.Kaplan@....com>,
        <Reshma.Lal@....com>, <Jeremy.Powell@....com>,
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        <alexander.shishkin@...ux.intel.com>, <thomas.lendacky@....com>,
        <tglx@...utronix.de>, <dgilbert@...hat.com>,
        <gregkh@...uxfoundation.org>, <dinechin@...hat.com>,
        <linux-coco@...ts.linux.dev>, <berrange@...hat.com>,
        <mst@...hat.com>, <tytso@....edu>, <jikos@...nel.org>,
        <joro@...tes.org>, <leon@...nel.org>,
        <richard.weinberger@...il.com>, <lukas@...ner.de>,
        <jejb@...ux.ibm.com>, <cdupontd@...hat.com>, <jasowang@...hat.com>,
        <sameo@...osinc.com>, <bp@...en8.de>, <seanjc@...gle.com>,
        <security@...nel.org>, Carlos Bilbao <carlos.bilbao@....com>
Subject: [PATCH] docs: security: Confidential computing intro and threat model

Kernel developers working on confidential computing operate under a set of
assumptions regarding the Linux kernel threat model that differ from the
traditional view. In order to effectively engage with the linux-coco
mailing list and contribute to ongoing kernel efforts, one must have a
thorough familiarity with these concepts. Add a concise,
architecture-agnostic introduction and threat model to provide a reference
for ongoing design discussions and to help developers gain a foundational
understanding of the subject.

Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>
Co-developed-by: Elena Reshetova <elena.reshetova@...el.com>
Signed-off-by: Elena Reshetova <elena.reshetova@...el.com>
Signed-off-by: Carlos Bilbao <carlos.bilbao@....com>
---
 .../security/confidential-computing.rst       | 245 ++++++++++++++++++
 Documentation/security/index.rst              |   1 +
 MAINTAINERS                                   |   6 +
 3 files changed, 252 insertions(+)
 create mode 100644 Documentation/security/confidential-computing.rst

diff --git a/Documentation/security/confidential-computing.rst b/Documentation/security/confidential-computing.rst
new file mode 100644
index 000000000000..98439ef7ff9f
--- /dev/null
+++ b/Documentation/security/confidential-computing.rst
@@ -0,0 +1,245 @@
+===============================
+Confidential Computing in Linux
+===============================
+
+.. contents:: :local:
+
+By: Elena Reshetova <elena.reshetova@...el.com> and Carlos Bilbao <carlos.bilbao@....com>
+
+Motivation
+==========
+
+Kernel developers working on confidential computing for the cloud operate
+under a set of assumptions regarding the Linux kernel threat model that
+differ from the traditional view. In order to effectively engage with the
+linux-coco mailing list and contribute to its initiatives, one must have a
+thorough familiarity with these concepts. This document provides a concise,
+architecture-agnostic introduction to help developers gain a foundational
+understanding of the subject.
+
+Overview and terminology
+========================
+
+Confidential Cloud Computing (CoCo) refers to a set of HW and SW
+virtualization technologies that allow Cloud Service Providers (CSPs) to
+provide stronger security guarantees to their clients (usually referred to
+as tenants) by excluding all the CSP's infrastructure and SW out of the
+tenant's Trusted Computing Base (TCB).
+
+While the concrete implementation details differ between technologies, all
+of these mechanisms provide increased confidentiality and integrity of CoCo
+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) </x86/tdx>` and
+:doc:`AMD Memory Encryption </x86/amd-memory-encryption>`.
+
+The basic CoCo layout includes the host, guest, the interfaces that
+communicate guest and host, a platform capable of supporting CoCo, and an
+intermediary between the guest virtual machine (VM) and the underlying
+platform that acts as security manager::
+
+    +-------------------+      +-----------------------+
+    | CoCo guest VM     |<---->|                       |
+    +-------------------+      |                       |
+      | Interfaces |           | CoCo security manager |
+    +-------------------+      |                       |
+    | Host VMM          |<---->|                       |
+    +-------------------+      |                       |
+                               |                       |
+    +--------------------+     |                       |
+    | CoCo platform      |<--->|                       |
+    +--------------------+     +-----------------------+
+
+The specific details of the CoCo intermediary vastly diverge between
+technologies, so much so that in some cases it will be HW and in others
+SW.
+
+Existing Linux kernel threat model
+==================================
+
+The components of the current Linux kernel threat model are::
+
+     +-----------------------+      +-------------------+
+     |                       |<---->| Userspace         |
+     |                       |      +-------------------+
+     |   External attack     |         | Interfaces |
+     |       vectors         |      +-------------------+
+     |                       |<---->| Linux Kernel      |
+     |                       |      +-------------------+
+     +-----------------------+      +-------------------+
+                                    | Bootloader/BIOS   |
+                                    +-------------------+
+                                    +-------------------+
+                                    | HW platform       |
+                                    +-------------------+
+
+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.
+
+Confidential Computing threat model and security objectives
+===========================================================
+
+Confidential Cloud Computing adds a new type of attacker to the above list:
+an untrusted and potentially malicious host. This can 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 VMM             |
+   |      manager          |     +------------------------+
+   |                       |     +------------------------+
+   |                       |<--->|   CoCo platform        |
+   +-----------------------+     +------------------------+
+
+While the traditional hypervisor 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 security objectives** can be summarized as follows:
+
+1. Preserve the confidentiality and integrity of CoCo guest private memory.
+2. Prevent privileged escalation from a host into a CoCo guest Linux kernel.
+
+The above security objectives result in two primary **Linux kernel CoCo
+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. Because of this, the host Denial of Service
+(DoS) attacks against CoCo guests are beyond the scope of this threat
+model.
+
+The **Linux CoCo 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 protections. 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, access to shared memory pages, interrupts allowed to be
+injected to the guest kernel by the host, as well as CoCo technology
+specific hypercalls. 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.
+
+The table below shows a threat matrix for the CoCo guest Linux kernel with
+the 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
+     - Mitigation strategy
+
+   * - Guest malicious configuration
+     - A malicious 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 violate the CoCo security objectives.
+     - The integrity of the guest's configuration passed via untrusted host
+       must be ensured by methods such as remote attestation and signing.
+       This should be largely transparent to the guest kernel and would
+       allow it to assume a trusted state at the time of boot.
+
+   * - CoCo guest data attacks
+     - A malicious 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.
+     - The CoCo guest is responsible for ensuring the confidentiality,
+       integrity and freshness of such data using well-established
+       security mechanisms. For example, for any guest external network
+       communications that are passed via the untrusted host, an end-to-end
+       secure session must be established between a guest and a trusted
+       remote endpoint using well-known protocols such as TLS.
+       This requirement also applies to protection of the guest's disk
+       image.
+
+   * - Malformed runtime input
+     - A malicious host injects malformed input via any communication
+       interface used by 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 classical side-channel
+       and/or transient execution attack vectors.
+     - The attestation or signing process cannot help to mitigate this
+       threat since this input is highly dynamic. Instead, a different set
+       of mechanisms is required:
+
+       1. *Limit the exposed attack surface*. Whenever possible, disable
+       complex kernel features and device drivers (not required for guest
+       operation) that actively use the communication interfaces between
+       the untrusted host and the guest. This is not a new concept for the
+       Linux kernel, since it already has mechanisms to disable external
+       interfaces such as attacker's access via USB/Thunderbolt subsystem.
+
+       2. *Harden the exposed attack surface*. Any code that uses such
+       interfaces must treat the input from the untrusted host as malicious
+       and do sanity checks before processing it. This can be ensured by
+       performing a code audit of such device drivers as well as employing
+       other standard techniques for testing the code robustness, such as
+       fuzzing. This is again a well-known concept for the Linux kernel
+       since all its networking code has been previously analyzed under
+       presumption of processing malformed input from a network attacker.
+
+   * - Malicious runtime input
+     - A malicious 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).
+     - Similarly, as with the previous attack vector, it is not possible to
+       use attestation mechanisms to address this threat. Instead, such
+       attack vectors (i.e. interfaces) must be either disabled or made
+       resistant to supplied host input.
+
+As can be seen from the above table, the potential mitigation strategies
+to secure the CoCo Linux guest kernel vary, but can be roughly split into
+mechanisms that either require or do not require changes to the existing
+Linux kernel code. One main goal of the CoCo security architecture is to
+limit the changes to the Linux kernel code to minimum, but at the same time
+to provide usable and scalable means to facilitate the security of a CoCo
+guest kernel for all the users of the CoCo ecosystem.
diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst
index 6ed8d2fa6f9e..5de51b130e6a 100644
--- a/Documentation/security/index.rst
+++ b/Documentation/security/index.rst
@@ -6,6 +6,7 @@ Security Documentation
    :maxdepth: 1
 
    credentials
+   confidential-computing
    IMA-templates
    keys/index
    lsm
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f86d02cb427..4a16727bf7f9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5307,6 +5307,12 @@ S:	Orphan
 W:	http://accessrunner.sourceforge.net/
 F:	drivers/usb/atm/cxacru.c
 
+CONFIDENTIAL COMPUTING THREAT MODEL
+M:	Elena Reshetova <elena.reshetova@...el.com>
+M:	Carlos Bilbao <carlos.bilbao@....com>
+S:	Maintained
+F:	Documentation/security/confidential-computing.rst
+
 CONFIGFS
 M:	Joel Becker <jlbec@...lplan.org>
 M:	Christoph Hellwig <hch@....de>
-- 
2.34.1

Powered by blists - more mailing lists