Message-ID: <4a25cfe8-39d7-1d0f-b89b-2d62bdb085c1@amd.com>
Date:   Wed, 6 Sep 2023 08:42:30 -0500
From:   Carlos Bilbao <carlos.bilbao@....com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     corbet@....net, 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, 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,
        Larry Dewey <larry.dewey@....com>
Subject: Re: [PATCH v4] docs: security: Confidential computing intro and
 threat model for x86 virtualization

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:

(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

Powered by blists - more mailing lists