lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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