-----Original Message-----
From: Carlos Bilbao <carlos.bilbao@xxxxxxx>
Sent: Monday, March 27, 2023 9:18 AM
To: corbet@xxxxxxx
Cc: linux-doc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
ardb@xxxxxxxxxx; kraxel@xxxxxxxxxx; dovmurik@xxxxxxxxxxxxx;
elena.reshetova@xxxxxxxxx; dave.hansen@xxxxxxxxxxxxxxx; Giani, Dhaval
<Dhaval.Giani@xxxxxxx>; Day, Michael <Michael.Day@xxxxxxx>; Paluri,
PavanKumar (Pavan Kumar) <PavanKumar.Paluri@xxxxxxx>; Kaplan, David
<David.Kaplan@xxxxxxx>; Lal, Reshma <Reshma.Lal@xxxxxxx>; Powell,
Jeremy <Jeremy.Powell@xxxxxxx>;
sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx;
alexander.shishkin@xxxxxxxxxxxxxxx; Lendacky, Thomas
<Thomas.Lendacky@xxxxxxx>; tglx@xxxxxxxxxxxxx; dgilbert@xxxxxxxxxx;
gregkh@xxxxxxxxxxxxxxxxxxx; dinechin@xxxxxxxxxx; linux-
coco@xxxxxxxxxxxxxxx; berrange@xxxxxxxxxx; mst@xxxxxxxxxx;
tytso@xxxxxxx; jikos@xxxxxxxxxx; joro@xxxxxxxxxx; leon@xxxxxxxxxx;
richard.weinberger@xxxxxxxxx; lukas@xxxxxxxxx; jejb@xxxxxxxxxxxxx;
cdupontd@xxxxxxxxxx; jasowang@xxxxxxxxxx; sameo@xxxxxxxxxxxx;
bp@xxxxxxxxx; seanjc@xxxxxxxxxx; security@xxxxxxxxxx; Bilbao, Carlos
<Carlos.Bilbao@xxxxxxx>
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@xxxxxxxxxxxxxxx>
Co-developed-by: Elena Reshetova <elena.reshetova@xxxxxxxxx>
Signed-off-by: Elena Reshetova <elena.reshetova@xxxxxxxxx>
Signed-off-by: Carlos Bilbao <carlos.bilbao@xxxxxxx>
---
.../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@xxxxxxxxx> and Carlos Bilbao
+<carlos.bilbao@xxxxxxx>
+
+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@xxxxxxxxx>
+M: Carlos Bilbao <carlos.bilbao@xxxxxxx>
+S: Maintained
+F: Documentation/security/confidential-computing.rst
+
CONFIGFS
M: Joel Becker <jlbec@xxxxxxxxxxxx>
M: Christoph Hellwig <hch@xxxxxx>
--
2.34.1
