Messages in this thread | | | Date | Tue, 25 Apr 2023 08:43:52 -0500 | Subject | Re: [PATCH] docs: security: Confidential computing intro and threat model | From | Carlos Bilbao <> |
| |
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
| |