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

[Carlos Bilbao <carlos.bilbao@amd.com>]

On 4/21/23 16:09, Kaplan, David wrote:
> [AMD Official Use Only - General]
> 
>> -----Original Message-----
>> From: Carlos Bilbao <carlos.bilbao@amd.com>
>> Sent: Monday, March 27, 2023 9:18 AM
>> To: corbet@lwn.net
>> Cc: linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>> ardb@kernel.org; kraxel@redhat.com; dovmurik@linux.ibm.com;
>> elena.reshetova@intel.com; dave.hansen@linux.intel.com; Giani, Dhaval
>> <Dhaval.Giani@amd.com>; Day, Michael <Michael.Day@amd.com>; Paluri,
>> PavanKumar (Pavan Kumar) <PavanKumar.Paluri@amd.com>; Kaplan, David
>> <David.Kaplan@amd.com>; Lal, Reshma <Reshma.Lal@amd.com>; Powell,
>> Jeremy <Jeremy.Powell@amd.com>;
>> sathyanarayanan.kuppuswamy@linux.intel.com;
>> alexander.shishkin@linux.intel.com; Lendacky, Thomas
>> <Thomas.Lendacky@amd.com>; tglx@linutronix.de; dgilbert@redhat.com;
>> gregkh@linuxfoundation.org; dinechin@redhat.com; linux-
>> coco@lists.linux.dev; berrange@redhat.com; mst@redhat.com;
>> tytso@mit.edu; jikos@kernel.org; joro@8bytes.org; leon@kernel.org;
>> richard.weinberger@gmail.com; lukas@wunner.de; jejb@linux.ibm.com;
>> cdupontd@redhat.com; jasowang@redhat.com; sameo@rivosinc.com;
>> bp@alien8.de; seanjc@google.com; security@kernel.org; Bilbao, Carlos
>> <Carlos.Bilbao@amd.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@linux.intel.com>
>> Co-developed-by: Elena Reshetova <elena.reshetova@intel.com>
>> Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
>> Signed-off-by: Carlos Bilbao <carlos.bilbao@amd.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@intel.com> and Carlos Bilbao
>> +<carlos.bilbao@amd.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@intel.com>
>> +M:   Carlos Bilbao <carlos.bilbao@amd.com>
>> +S:   Maintained
>> +F:   Documentation/security/confidential-computing.rst
>> +
>>   CONFIGFS
>>   M:   Joel Becker <jlbec@evilplan.org>
>>   M:   Christoph Hellwig <hch@lst.de>
>> --
>> 2.34.1
> 
> Reviewed-by: David Kaplan <david.kaplan@amd.com>


Does anyone have other concerns or questions? Otherwise, Jon, my "V2" will
be the same text with David's RB tag for the commit.

Thanks,
Carlos