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