lkml.org 
[lkml]   [2023]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] docs: security: Confidential computing intro and threat model
From
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

\
 
 \ /
  Last update: 2023-04-25 15:45    [W:0.236 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site