RE: [PATCH] docs: security: Confidential computing intro and threat model

[Kaplan, David]

[AMD Official Use Only - General]

> -----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

Reviewed-by: David Kaplan <david.kaplan@xxxxxxx>