Re: [PATCH v4] docs: security: Confidential computing intro and threat model for x86 virtualization

[Carlos Bilbao <carlos.bilbao@amd.com>]

On 9/11/23 09:16, Carlos Bilbao wrote:
> 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.

Jon, I believe we have addressed all major concerns and this is good for
merge.

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

Thanks,
Carlos