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