요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
======================================================
Confidential Computing in Linux for x86 virtualization
======================================================
.. contents:: :local:
By: Elena Reshetova <[email protected]> and Carlos Bilbao <[email protected]>
Motivation
==========
Kernel developers working on confidential computing for virtualized
environments in x86 operate under a set of assumptions regarding the Linux
kernel threat model that differ from the traditional view. Historically,
the Linux threat model acknowledges attackers residing in userspace, as
well as a limited set of external attackers that are able to interact with
the kernel through various networking or limited HW-specific exposed
interfaces (USB, thunderbolt). The goal of this document is to explain
additional attack vectors that arise in the confidential computing space
and discuss the proposed protection mechanisms for the Linux kernel.
Overview and terminology
========================
Confidential Computing (CoCo) is a broad term covering a wide range of
security technologies that aim to protect the confidentiality and integrity
of data in use (vs. data at rest or data in transit). At its core, CoCo
solutions provide a Trusted Execution Environment (TEE), where secure data
processing can be performed and, as a result, they are typically further
classified into different subtypes depending on the SW that is intended
to be run in TEE. This document focuses on a subclass of CoCo technologies
that are targeting virtualized environments and allow running Virtual
Machines (VM) inside TEE. From now on in this document will be referring
to this subclass of CoCo as 'Confidential Computing (CoCo) for the
virtualized environments (VE)'.
CoCo, in the virtualization context, refers to a set of HW and/or SW
technologies that allow for stronger security guarantees for the SW running
inside a CoCo VM. Namely, confidential computing allows its users to
confirm the trustworthiness of all SW pieces to include in its reduced
Trusted Computing Base (TCB) given its ability to attest the state of these
trusted components.
While the concrete implementation details differ between technologies, all
available mechanisms aim to provide increased confidentiality and
integrity for the VM's 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) </arch/x86/tdx>` and
`AMD Memory Encryption <https://www.amd.com/system/files/techdocs/sev-snp-strengthening-vm-isolation-with-integrity-protection-and-more.pdf>`_.
The basic CoCo guest layout includes the host, guest, the interfaces that
communicate guest and host, a platform capable of supporting CoCo VMs, and
a trusted intermediary between the guest VM and the underlying platform
that acts as a security manager. The host-side virtual machine monitor
(VMM) typically consists of a subset of traditional VMM features and
is still in charge of the guest lifecycle, i.e. create or destroy a CoCo
VM, manage its access to system resources, etc. However, since it
typically stays out of CoCo VM TCB, its access is limited to preserve the
security objectives.
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 |<--->| |
+--------------------+ +-----------------------+
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 |
+-------------------+
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.
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.
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.
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.
* - Malicious runtime input
- A misbehaving 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).
resistant to supplied host input.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
문서의 목적과 확장된 가정
1-21이 문서는 x86 가상화 환경의 Confidential Computing을 Linux에서 구현할 때 적용하는 위협 모델을 설명한다. 작성자는 Elena Reshetova와 Carlos Bilbao이며, 문서 안의 지역 목차를 제공한다.
전통적인 Linux 위협 모델은 주로 사용자 공간 공격자와, networking 또는 USB·Thunderbolt처럼 제한적으로 노출된 hardware interface를 통해 kernel과 상호 작용하는 일부 외부 공격자를 다룬다. Confidential Computing 환경의 kernel 개발자는 이와 다른 가정을 추가로 사용해야 한다.
목표는 Confidential Computing에서 새롭게 생기는 공격 vector를 설명하고, Linux kernel에 제안된 보호 mechanism을 논의하는 것이다.
기존 공격자 집합에 가상화 host를 추가해 보호 경계를 다시 정의한다.
======================================================
Confidential Computing in Linux for x86 virtualization
======================================================
.. contents:: :local:
By: Elena Reshetova <[email protected]> and Carlos Bilbao <[email protected]>
Motivation
==========
Kernel developers working on confidential computing for virtualized
environments in x86 operate under a set of assumptions regarding the Linux
kernel threat model that differ from the traditional view. Historically,
the Linux threat model acknowledges attackers residing in userspace, as
well as a limited set of external attackers that are able to interact with
the kernel through various networking or limited HW-specific exposed
interfaces (USB, thunderbolt). The goal of this document is to explain
additional attack vectors that arise in the confidential computing space
and discuss the proposed protection mechanisms for the Linux kernel.
CoCo, TEE, VE와 TCB
22-52Confidential Computing(CoCo)은 저장 중이거나 전송 중인 데이터가 아니라 사용 중인 데이터의 confidentiality와 integrity를 보호하려는 광범위한 security technology를 뜻한다. 핵심은 안전한 data processing을 수행하는 Trusted Execution Environment(TEE)이며, TEE에서 실행하려는 software의 종류에 따라 여러 하위 유형으로 나뉜다.
이 문서는 TEE 안에서 Virtual Machine(VM)을 실행하는 가상화 환경용 CoCo 하위 유형에 초점을 맞추고, 이를 이후 `Confidential Computing (CoCo) for the virtualized environments (VE)`라고 부른다.
가상화 문맥의 CoCo는 CoCo VM 안에서 실행되는 software에 더 강한 security guarantee를 제공하는 hardware·software 기술 집합이다. 사용자는 trusted component의 상태를 attestation할 수 있으므로 축소된 Trusted Computing Base(TCB)에 포함될 모든 software가 신뢰할 수 있는지 확인할 수 있다.
구체 구현은 기술마다 다르지만 모두 guest memory와 execution state, 즉 vCPU register의 confidentiality·integrity를 높이고, guest interrupt injection을 더 엄격히 통제하며, guest-host page mapping을 제어하는 mechanism을 제공한다. x86 세부 기술은 Intel Trust Domain Extensions(TDX) 문서와 AMD SEV-SNP memory encryption 자료를 참조한다.
이 문서에서 사용하는 보호 대상과 신뢰 경계를 정리한다.
Overview and terminology
========================
Confidential Computing (CoCo) is a broad term covering a wide range of
security technologies that aim to protect the confidentiality and integrity
of data in use (vs. data at rest or data in transit). At its core, CoCo
solutions provide a Trusted Execution Environment (TEE), where secure data
processing can be performed and, as a result, they are typically further
classified into different subtypes depending on the SW that is intended
to be run in TEE. This document focuses on a subclass of CoCo technologies
that are targeting virtualized environments and allow running Virtual
Machines (VM) inside TEE. From now on in this document will be referring
to this subclass of CoCo as 'Confidential Computing (CoCo) for the
virtualized environments (VE)'.
CoCo, in the virtualization context, refers to a set of HW and/or SW
technologies that allow for stronger security guarantees for the SW running
inside a CoCo VM. Namely, confidential computing allows its users to
confirm the trustworthiness of all SW pieces to include in its reduced
Trusted Computing Base (TCB) given its ability to attest the state of these
trusted components.
While the concrete implementation details differ between technologies, all
available mechanisms aim to provide increased confidentiality and
integrity for the VM's 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) </arch/x86/tdx>` and
`AMD Memory Encryption <https://www.amd.com/system/files/techdocs/sev-snp-strengthening-vm-isolation-with-integrity-protection-and-more.pdf>`_.
CoCo guest 구성과 security manager
53-82기본 CoCo guest 구성에는 host, guest, guest와 host를 잇는 interface, CoCo VM을 지원하는 platform, 그리고 guest VM과 기반 platform 사이에서 security manager 역할을 하는 trusted intermediary가 있다.
Host-side VMM은 보통 전통적인 VMM 기능의 일부로 구성되며 CoCo VM 생성·삭제, system resource 접근 관리 같은 guest lifecycle을 계속 담당한다. 그러나 큰 software attack surface 때문에 일반적으로 CoCo VM TCB 밖에 있으므로 security objective를 보존하도록 접근이 제한된다.
원문의 `<--->` 선은 CoCo security manager가 guest, host VMM, CoCo platform과 양방향으로 통신하는 channel 또는 interface를 나타낸다. Guest와 host 사이에도 별도 interface가 있다. Security manager 구현은 기술마다 크게 달라 hardware일 수도 있고 순수 software일 수도 있다.
원문 ASCII 구성도의 양방향 통신 관계를 구조화했다.
TCB 밖의 host가 lifecycle을 관리하되 security manager가 보호 경계를 강제한다.
The basic CoCo guest layout includes the host, guest, the interfaces that
communicate guest and host, a platform capable of supporting CoCo VMs, and
a trusted intermediary between the guest VM and the underlying platform
that acts as a security manager. The host-side virtual machine monitor
(VMM) typically consists of a subset of traditional VMM features and
is still in charge of the guest lifecycle, i.e. create or destroy a CoCo
VM, manage its access to system resources, etc. However, since it
typically stays out of CoCo VM TCB, its access is limited to preserve the
security objectives.
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 |<--->| |
+--------------------+ +-----------------------+
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.
기존 Linux 위협 모델의 구성
83-107기존 Linux kernel 위협 모델의 구성도에는 userspace, Linux kernel, bootloader/BIOS, hardware platform과 외부 attack vector가 있다. 외부 vector는 userspace와 kernel 모두에 접근할 수 있다.
원문 그림은 boot 과정의 bootloader와 kernel 통신을 명시적으로 표시하지 않는다. `Interfaces` 상자는 system call, kernel API, device driver를 비롯해 kernel과 userspace가 통신하도록 하는 여러 interface를 뜻한다.
원문 ASCII 구성도에서 각 계층과 공격 연결을 정리한다.
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 |
+-------------------+
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.
기존 공격자와 신뢰 가정
108-124기존 모델은 trusted hardware platform에서 실행하며 firmware와 bootloader 전체가 TCB에 포함된다고 가정한다. 주된 공격자는 userspace에 있고, 충분한 권한으로 trusted action을 수행하는 경우가 아니라면 userspace에서 들어오는 모든 data는 일반적으로 신뢰하지 않는다.
또한 Ethernet·Wireless·Bluetooth 같은 활성 외부 network, USB·Thunderbolt 같은 노출 hardware interface, offline disk content 변경 능력을 가진 외부 공격자도 고려한다.
외부 공격자는 보통 먼저 userspace 취약점을 이용하지만, 특히 물리 접근이 있으면 kernel을 직접 공격할 수도 있다. 직접 kernel attack 사례로 `CVE-2019-19524`, `CVE-2022-0435`, `CVE-2020-24490`이 제시된다.
신뢰 여부와 대표 진입점을 구분한다.
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.
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.
CoCo가 추가하는 host 공격자
125-159Confidential Computing은 잠재적으로 오동작하는 host를 새로운 공격자로 추가한다. 여기에는 전통적인 VMM 일부 또는 전체가 포함될 수 있다. Host/VMM은 software attack surface가 커서 보통 CoCo VM TCB 밖에 둔다.
이 가정이 host나 VMM이 의도적으로 악성이라는 뜻은 아니다. CoCo VM TCB를 작게 유지하는 자체가 security value를 갖기 때문이다. 이 공격자는 원격 network 공격자와 달리 같은 물리 machine에 있고, guest kernel과 대부분 hardware 사이의 통신을 통제하므로 더 강력한 외부 공격자로 볼 수 있다.
확장된 구성도에서 CoCo guest VM은 userspace, interface, Linux kernel, bootloader/BIOS를 포함한다. 외부 attack vector는 guest userspace·kernel에 닿고, security manager는 guest와 host-side VMM 및 CoCo platform 사이의 양방향 경계를 중재한다. Host/VMM과 guest 사이 interface는 명시적인 attack surface다.
원문 두 번째 ASCII 구성도의 관계와 신뢰 상태를 보존한다.
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 |
+-----------------------+ +------------------------+
보안 목표, 자산과 DoS 제외
160-188전통적인 host는 guest data에 제한 없이 접근하고 이를 공격에 이용할 수 있다. CoCo system은 guest data confidentiality와 integrity protection 같은 기능으로 이러한 공격을 완화하며, 이 위협 모델은 해당 기능이 제공되고 손상되지 않았다고 가정한다.
Linux kernel CoCo VM의 첫 번째 security objective는 guest private memory와 register의 confidentiality·integrity를 보존하는 것이다. 두 번째는 host에서 CoCo guest Linux kernel로 privilege escalation이 일어나지 않게 하는 것이다.
Host/VMM은 guest를 생성·삭제·일시 중지하려면 어느 정도 권한이 필요하지만, 이런 lifecycle operation이 공격자가 guest kernel에 접근하는 통로가 되어서는 안 된다. 이에 따른 주요 자산은 guest kernel execution context와 guest kernel private memory 두 가지다.
Host는 CPU time, guest가 소비할 memory, network bandwidth 같은 CoCo guest resource를 완전히 통제하고 언제든 접근을 거부할 수 있다. 따라서 host가 CoCo guest에 가하는 Denial of Service(DoS)는 이 위협 모델의 범위 밖이다.
보호 목표·자산과 명시적 제외 대상을 구분한다.
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.
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.
Host에 노출되는 attack surface
189-207Linux CoCo VM attack surface는 CoCo guest Linux kernel이 untrusted host에 노출하면서 CoCo software·hardware 보호로 덮이지 않는 모든 interface다. 일반 side-channel과 transient execution side-channel도 포함한다.
명시적 interface에는 port I/O, MMIO, DMA, PCI configuration space, host-side VMM을 향한 VMM-specific hypercall, shared memory page, host가 guest kernel에 주입할 수 있는 interrupt, 존재하는 경우 CoCo 기술 전용 hypercall이 포함된다.
Host는 보통 CoCo guest 생성 과정도 통제하여 firmware·bootloader image, kernel image, kernel command line을 guest에 적재한다. 이 모든 data는 attestation으로 integrity와 authenticity가 확립될 때까지 untrusted로 취급해야 한다.
보호 경계 밖에서 host가 제어하거나 관찰할 수 있는 입력을 분류한다.
Host가 적재한 boot 자료는 attestation 전까지 신뢰하지 않는다.
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.
위협 행렬: 구성 변조와 전송 데이터
208-234위협 행렬은 CoCo guest Linux kernel의 위협 유형과 설명을 제시하며 구체적인 mitigation 전략은 다루지 않는다. 여기서 guest, host, platform은 모두 CoCo 전용 형태를 뜻한다.
`Guest malicious configuration`은 오동작하는 host가 guest firmware·bootloader, guest kernel·module binary, guest command line parameter 중 하나를 변경하는 공격이다. CoCo guest 안에서 실행되는 code integrity를 깨뜨려 CoCo security objective를 위반한다.
`CoCo guest data attacks`에서는 host가 guest와 host-managed physical·virtual device 사이를 이동하는 guest data를 완전히 통제한다. 따라서 이 전송 data의 confidentiality, integrity, freshness를 각각 공격할 수 있다.
정적 구성과 host-managed device 경로에서 발생하는 위협이다.
.. 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·malicious runtime input
235-253`Malformed runtime input`은 host가 guest kernel code가 사용하는 통신 interface로 형식이 잘못된 입력을 주입하는 공격이다. Code가 이를 올바르게 처리하도록 준비되지 않았다면 host에서 guest kernel로 privilege escalation이 일어날 수 있다. 전통적인 side-channel과 transient execution attack vector도 이 범주에 포함된다.
`Malicious runtime input`은 형식 자체는 올바르지만 값이 guest kernel security에 영향을 주도록 조작된 입력이다. 악성 time 값을 제공하거나 guest random number generator에 악성 entropy를 제공하는 사례가 있다.
Event timing 자체도 특정 guest kernel action을 유발한다면 attack vector가 될 수 있다. 예를 들어 host가 주입한 interrupt를 처리하는 시점을 조작할 수 있다. 원문의 마지막 문장은 공급된 host input에 대해 저항성을 가져야 한다는 요구를 덧붙인다.
Runtime 입력의 문법적 유효성과 악의적 의미를 구분한다.
모든 host-controlled 값과 시점을 security input으로 다룬다.
* - 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.
* - Malicious runtime input
- A misbehaving 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).
resistant to supplied host input.
요약·해설
snp-tdx-threat-model.rst:1-253x86 CoCo VM에서 host/VMM을 TCB 밖의 강력한 공격자로 보고, private memory·register와 kernel execution context를 보호하는 목표 및 host-controlled I/O·boot·runtime 입력의 위협을 정의합니다.