Messages in this thread | | | Date | Mon, 11 Sep 2023 09:16:57 -0500 | Subject | Re: [PATCH v4] docs: security: Confidential computing intro and threat model for x86 virtualization | From | Carlos Bilbao <> |
| |
On 9/6/23 08:42, Carlos Bilbao wrote: > On 9/5/23 10:49, Greg KH wrote: >> On Tue, Sep 05, 2023 at 10:26:56AM -0500, Carlos Bilbao wrote: >>> +In the following diagram, the "<--->" lines represent bi-directional >>> +communication channels or interfaces between the CoCo security manager and >>> +the rest of the components (data flow for guest, host, hardware) :: >>> + >>> + +-------------------+ +-----------------------+ >>> + | CoCo guest VM |<---->| | >>> + +-------------------+ | | >>> + | Interfaces | | CoCo security manager | >>> + +-------------------+ | | >>> + | Host VMM |<---->| | >>> + +-------------------+ | | >>> + | | >>> + +--------------------+ | | >>> + | CoCo platform |<--->| | >>> + +--------------------+ +-----------------------+ >> >> I don't understand what "| Interfaces |" means here. There is, or is >> not, a communication channel between the CoC guest VM and the Host VMM? >> >> What does "interface" mean? > > Explained below :) > >> >>> + >>> +The specific details of the CoCo security manager vastly diverge between >>> +technologies. For example, in some cases, it will be implemented in HW >>> +while in others it may be pure SW. >>> + >>> +Existing Linux kernel threat model >>> +================================== >>> + >>> +The overall components of the current Linux kernel threat model are:: >>> + >>> + +-----------------------+ +-------------------+ >>> + | |<---->| Userspace | >>> + | | +-------------------+ >>> + | External attack | | Interfaces | >>> + | vectors | +-------------------+ >>> + | |<---->| Linux Kernel | >>> + | | +-------------------+ >>> + +-----------------------+ +-------------------+ >>> + | Bootloader/BIOS | >>> + +-------------------+ >>> + +-------------------+ >>> + | HW platform | >>> + +-------------------+ >> >> >> Same here, what does "Interfaces" mean? >> >> And external attack vectors can't get to the kernel without going >> through userspace (or the HW platform), right? >> >>> +There is also communication between the bootloader and the kernel during >>> +the boot process, but this diagram does not represent it explicitly. The >>> +"Interfaces" box represents the various interfaces that allow >>> +communication between kernel and userspace. This includes system calls, >>> +kernel APIs, device drivers, etc. >> >> Ah, you define that here now. >> >> But the kernel talks to the Bootloader/BIOS after things are up and >> running all the time. > > That's true. Here's some alternatives you might like more:
If nobody has any strong opinions regarding this alternative diagrams, I'd like to know if there are any objections left with the current threat model.
> > (a) > > +-----------------------+ +-------------------+ > | |<---->| Userspace | > | | +-------------------+ > | External attack | | Interfaces | > | vectors | +-------------------+ > | |<---->| Linux Kernel | > | | +-------------------+ > | | | Interfaces | > | | +-------------------+ > | |<---->| Bootloader/BIOS | > | | +-------------------+ > | | | Interfaces | > | | +-------------------+ > | |<---->| HW platform | > | | +-------------------+ > +-----------------------+ > > (b) > > > > +-------------------+ > ┌─────── | Userspace | > │ +-------------------+ > │ | Interfaces | > +-------------------+ > External ─── | Linux Kernel | > attack +-------------------+ > vectors | Interfaces | > │ │ +-------------------+ > │ └─────────| Bootloader/BIOS | > │ +-------------------+ > │ | Interfaces | > │ +-------------------+ > └────────────| HW platform | > +-------------------+ > > > (c) > > ┌─────────────────┐ > │ │ > │ Userspace ├─────────┐ > │ │ │ > ├──────▲───────▲──┤ │ > ├──▼───────▼──────┤ │ > │ Linux kernel │ │ > │ ├───── External > ├──▲──────▲───────┤ attack > ├─────▼───────▼───┤ vectors > │ Bootloader/ │ │ │ > │ BIOS ├───────┘ │ > ├───────▲─────▲───┤ │ > ├───▼───────▼─────┤ │ > │ │ │ > │ HW Platform │ │ > │ ├───────────┘ > └─────────────────┘ > > ┌─▲─┐ > └───┘ Interfaces > >> >> Same goes with the HW platform, the kernel talks to it too. >> >>> +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. >> >> Ok, but again, your diagram is odd, the text seems correct though. > > My hope is that everyone can understand the updated diagram we pick with > the explanation of what Interfaces means in this context. > >> >>> +Regarding external attack vectors, it is interesting to note that in most >>> +cases external attackers will try to exploit vulnerabilities in userspace >>> +first, but that it is possible for an attacker to directly target the >>> +kernel; particularly if the host has physical access. Examples of direct >>> +kernel attacks include the vulnerabilities CVE-2019-19524, CVE-2022-0435 >>> +and CVE-2020-24490. >>> + >>> +Confidential Computing threat model and its security objectives >>> +=============================================================== >>> + >>> +Confidential Computing adds a new type of attacker to the above list: a >>> +potentially misbehaving host (which can also include some part of a >>> +traditional VMM or all of it), which is typically placed outside of the >>> +CoCo VM TCB due to its large SW attack surface. It is important to note >>> +that this doesn’t imply that the host or VMM are intentionally >>> +malicious, but that there exists a security value in having a small CoCo >>> +VM TCB. This new type of adversary may 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/Host-side VMM | >>> + | manager | +------------------------+ >>> + | | +------------------------+ >>> + | |<--->| CoCo platform | >>> + +-----------------------+ +------------------------+ >>> + >>> +While traditionally the host 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 VM security objectives** can be summarized as >>> follows: >>> + >>> +1. Preserve the confidentiality and integrity of CoCo guest's private >>> +memory and registers. >> >> Preserve it from whom? > > From unauthorized access, I could update this sentence. > >> >>> +2. Prevent privileged escalation from a host into a CoCo guest Linux >>> kernel. >>> +While it is true that the host (and host-side VMM) requires some level of >>> +privilege to create, destroy, or pause the guest, part of the goal of >>> +preventing privileged escalation is to ensure that these operations do not >>> +provide a pathway for attackers to gain access to the guest's kernel. >>> + >>> +The above security objectives result in two primary **Linux kernel CoCo >>> +VM 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. Examples of resources include CPU time, memory >>> +that the guest can consume, network bandwidth, etc. Because of this, the >>> +host Denial of Service (DoS) attacks against CoCo guests are beyond the >>> +scope of this threat model. >>> + >>> +The **Linux CoCo VM 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 protection. 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 (towards Host-side VMM), access to shared memory pages, >>> +interrupts allowed to be injected into the guest kernel by the host, as >>> +well as CoCo technology-specific hypercalls, if present. 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 via attestation. >>> + >>> +The table below shows a threat matrix for the CoCo guest Linux kernel but >>> +does not discuss 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 >>> + >>> + * - Guest malicious configuration >>> + - A misbehaving 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 violates the CoCo security objectives. >>> + >>> + * - CoCo guest data attacks >>> + - A misbehaving 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. >>> + >>> + * - Malformed runtime input >>> + - A misbehaving host injects malformed input via any communication >>> + interface used by the 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 traditional >>> + side-channel and/or transient execution attack vectors. >> >> ok, good luck with that! side-channel attack vectors are going to be >> interesting for you to attempt to handle. >> >> Anyway, you are setting yourself up to treat ALL data coming into any >> kernel interface as potentially malicious, right? I welcome the patches >> to all of the drivers you are using to attempt to handle this properly, >> and to cover the performance impact that it is going to cause (check all >> the disk i/o packets!) Good Luck! >> >> greg k-h >> > > Thanks, > Carlos >
Thanks, Carlos
| |