diff --git a/Cargo.toml b/Cargo.toml index c24ed5248..89981694d 100644 --- a/Cargo.toml +++ b/Cargo.toml @@ -14,6 +14,7 @@ members = [ "confidential-datahub/secret", "image-rs", "ocicrypt-rs", + "tdm" ] [workspace.dependencies] diff --git a/README.md b/README.md index 9ebf89d69..970f00ab2 100644 --- a/README.md +++ b/README.md @@ -15,5 +15,8 @@ Rust implementation of the container image management library. [ocicrypt-rs](ocicrypt-rs) Rust implementation of the OCI image encryption library. +[Trusted Device Manager](tdm) +A TEE-IO (a.k.a. trusted-IO) devices manager for confidential guests. + ## License [![FOSSA Status](https://app.fossa.com/api/projects/git%2Bgithub.com%2Fconfidential-containers%2Fimage-rs.svg?type=large)](https://app.fossa.com/projects/git%2Bgithub.com%2Fconfidential-containers%2Fimage-rs?ref=badge_large) diff --git a/tdm/Cargo.toml b/tdm/Cargo.toml new file mode 100644 index 000000000..6c8d65e4d --- /dev/null +++ b/tdm/Cargo.toml @@ -0,0 +1,11 @@ +[package] +name = "tdm" +version = "0.1.0" +description = "A TEE-IO device manager for confidential guests" +repository = "https://github.com/confidential-containers/guest-components/tree/main/tdm" +readme = "README.md" +license = "Apache-2.0" +authors = ["The Trusted Device Manager Authors"] +edition = "2021" + +[dependencies] diff --git a/tdm/README.md b/tdm/README.md new file mode 100644 index 000000000..f81626892 --- /dev/null +++ b/tdm/README.md @@ -0,0 +1,4 @@ +# Trusted Device Manager + +The Trusted Device Manager (TDM) is a confidential guest component for handling +trusted IO operations. diff --git a/tdm/docs/architecture.md b/tdm/docs/architecture.md new file mode 100644 index 000000000..f466a2227 --- /dev/null +++ b/tdm/docs/architecture.md @@ -0,0 +1,262 @@ +# Trusted Device Manager Architecture + +This is an architecture document for the Trusted Device Manager (TDM), a +confidential guest, userspace component for implementing trusted I/O. + +## Goals + +In order to achieve high performance Input/Output (I/O) operations, confidential +VMs must extend their trust boundary to include a composition of directly +assigned, TEE-IO-capable devices/functions. Without this ability, confidential +VMs have to resort to using para-virtualized I/O using non-confidential memory +regions, which has performance impacts due to memory copies and negates the use +of directly assigned devices. + +Silicon vendors and device manufacturers provide TEE-IO compliant hardware +implementations. Intel TDX Connect or AMD SEV-TIO, for example, rely on device +manufacturers to support the TDISP, SPDM and PCIe IDE protocols to give +confidential guests access to trusted MMIO and secure DMA between them and +devices which trustworthiness is verifiable. + +The TEE-IO security model is built on top of this hardware support but also on +the ability for confidential guests to ultimately decide if they accept or +reject TEE-IO compliant devices into their TCB. The TDM, as a confidential guest +component, is the TCB acceptance decision maker and is responsible for notifying +the underlying Trusted Security Manager (TSM) about its decision. By accepting a +TDI into the guest TCB, the TDM explicitly requests the TSM to move the device +into an operational state. The TDM builds the acceptance decision after having +verified and authenticated the TDI. It must also attest of the assigned device +trustworthiness, through a local or remote attestation process. + +## Scope + +## Architectural Overview + +High-level view: + +``` + + + ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ + ┃ Confidential Guest ┃ + ┃ ╔═══════════════════════╗ ┃ + ┃ ║Trusted Device Manager ║ ┃ + ┃ ║ ║ ┃ + ┃ ║┌─────────────────────┐║ ┃ + ┃ ║│ Attestation Module │║ ┃ + ┃ ┌───▷║│ │║ ┃ + ┃ │ ║└─────────────────────┘║ ┃ + ┃ │ ║ ║ ┃ + ┃ │ ║ ╔════════╗ ╔════════╗ ║ ┃ + ┃ │ ╚═╣ TEE ╠═╣ TEE ╠═╝ ┃ + ┃ │ ║ Plugin ║ ║ Plugin ║ ┃ + ┃ udev ╚════════╝ ╚════════╝ ┃ + ┃ (PCIe device △ ┃ + ┃ detection) │ ┃ + ┃ │ Device Evidence ┃ + ┃ │ Accept/Reject ┃ + ┃ │ │ ┃ + ┃ │ ▽ ┃ + ┃ │ ┌───────┐ ┃ + ┃ │ ┌───────────────┤TEE ABI├────┐ ┃ + ┃ │ │ Linux Guest └───────┘ │ ┃ + ┃ └──│ Kernel │ ┃ + ┃ └────────────────────────────┘ ┃ + ┗━━━━━━━━━━━━━━━━━━━━━━━━△━━━━━━━━━━━━━━━━━━━━━━┛ + │ + │ + │ + TEE-IO ABI + │ + │ + ▽ +┏━━━━━━━━━━━━━━━━━━━━━━━┓ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ +┃ ┃ ┃ ┃ +┃ Host VMM/Hypervisor ┃ ┃ Trusted Security Manager ┃ +┃ (KVM+QEMU/CLH) ┃◁──────TEE ABI─────▷┃ (TDX Module, ASP, etc) ┃ +┃ ┃ ┃ ┃ +┗━━━━━━━━━━━━━━━━━━━━━━━┛ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ + △ + ┃ + PCIe Bus + ┃ + ┃ + ▽ +┏━━━━━━━━━━━━━━━━━━━━━━━┓ +┃ TEE-IO Compliant PCIe ┃ +┃ Device ┃ +┗━━━━━━━━━━━━━━━━━━━━━━━┛ + +``` + +In order for the TDM to achieve the above described goals, it must be able to: + +1. Detect VMM-assigned PCIe devices. This relies on the Linux kernel `udev` + subsystem. TDM also assumes the TSM must not enable any DMA or MMIO mappings + before it accepted the device. +2. Authenticate the assigned device. Both authentication and attestation of the + TDI relies on the ability for the TDM to retrieve a certificate chain and an + attestation evidence. This is provided by the Linux kernel confidential + computing ABI, which is generally exposed as a vendor-specific, ioctl-based + character device. +3. Verify the assigned device. Before accepting a TDI into the confidential + guest TCB, the TDM must use the Linux kernel CoCo ABI to verify the following + security attributes from the TSM: + * Device link state + * TDI state + * TDI MMIO mappings +4. Attest of the assigned device trustworthiness. As part of the overall device + verification process, the TDM must run a local or remote attestation of the + device attestation evidence: + 1. For running local device attestation, the TDM needs to practically become a + Relying Party. + 2. In order to support remote device attestation, the TDM would rely on + existing guest components like the attestation agent. +5. Notify the TSM of it TDI acceptance decision. Here as well, this relies on + the Linux kernel CoCo ABI. + +This leads to a natural split of the TDM software architecture into 4 main +modules: + +1. The **TDM Core** runs the main TDM flows and managing confidential guest + assignment with the support of the detection, ABI plugins and attestation + modules. +2. The **Device Detection** module traps device discovery, assignment and + removal from the confidential guest PCIe emulated bus. +3. The **Linux CoCo ABI plugins** abstracts the vendor specific CoCo Linux + kernel ABIs in order expose a vendor-agnostic internal interface for the TDM + core to consume. +4. The **Device Attestation** module is responsible for verifying a device + attestation evidence, which can be achieved through local or remote + attestation. This module acts as a device attestation relying party to + support the former, while it relies on the Attestation Agent API to support + the latter case. It provides attestation results back to the TDM core. + +``` + ┌────────────────────────┐ + │ Trusted Device Manager │ + ┌─────────────────────────────────┴────────────────────────┴────────────────────────────────────┐ + │ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │ + │ ┌───────────┐ ┌─────────────┐ ┌───────────┐ │ + │ │ Local │ │ │ Attester │ │ │Attestation│ │ + │ │Attestation│─────▷│ Crate │──────▷│ Service │◁─┐ │ + │ └───────────┘ │ └─────────────┘ │ │ Crate │ │ │ + │ ┌──────────┐ ┌────────────┐ │ └───────────┘ │ │ + │ │ Device │ │ Device │ │ │ │ ┌─────────┐ │ │ + ┏━╋━━▶│Detection │ │Attestation │◁──Attestation │Policies │───┘ │ + ┃ │ │ Module │ │ Module │ Token │ │ │ ├─────────┤ │ + ┃ │ └──────────┘ └────────────┘ │ │Reference│ │ + ┃ │ △ △ ┌───────────┐ │ ┌─────────────┐ │ │ Values │ │ + ┃ │ └──────┐┌─────┘ │ Remote │ │ Attestation │ └─────────┘ │ + ┃ │ ││ │Attestation│────┼▷│ Agent │ │ │ + ┃ │ ▽▽ └───────────┘ │ Crate │ │ + ┃ │ ┌──────────────┐ │ └─────────────┘ │ │ + ┃ │ │ Core Module │ │ + ┃ │ └──────────────┘ │ Attestation │ │ + ┃ │ △ Agent │ + PCIe ┃ │ └────┐ └ ─ ─ ─ ─ ─ ─ ─ ─ ┘ │ + udev ┃ │ │ │ +events┃ │ ▽ │ + ┃ │ ┌─────────────────────────────────┐ │ + ┃ │ │ TDI Management Module │ │ + ┃ │ └─────────────────────────────────┘ │ + ┃ │ ┌──────────┐┌──────────┐┌─────────┐ │ + ┃ │ │TDX Plugin││SEV Plugin││SE Plugin│ │ + ┃ │ └──────────┘└──────────┘└─────────┘ │ + ┃ │ ┃ │ + ┃ └──────────────────────╋────────────────────────────────────────────────────────────────────────┘ + ┃ ┃ + ┃ CoCo ABI + ┃ ┃ + ┃ ▼ + ┃ ┌──────────────────────────────────────────┐ + ┗━━│ Linux Guest Kernel │ + └──────────────────────────────────────────┘ +``` + +### TDM Core + +The TDM core module interacts with three other TDM components: + +1. The device detection module. It monitors udev events to detect PCI devices + addition and removal from the guest emulated PCI bus. This module calls into + the TDM core to notify it about both event types. The TDM core then relies on + the following two modules to verify, attest and accept newly detected + devices. Only TDM-accepted TDIs are visible and available to the rest of the + guest software stack. +2. The TDI management module. This is an abstraction over the Linux CoCo + vendor-specific ABI and the TDM core calls into this module in order to + communicate with the TSM. The TDI management module module abstracts the + vendor-specific TSM interfaces in order for the TDM to: + * Retrieve a certificate chain for any newly detected device. + * Retrieve an attestation evidence for any newly detected device. This is + optional as the evidence may be delivered as part of the device certificate + chain. + * Check the physical device link state and verify that it is confidentiality + and integrity protected, as provided by the PCI IDE protocol. The TSM + manages the IDE keys and must track the device physical link state for any + assigned devices. + * Check for the TDI state in order to verify that it is in the (TDISP) locked + state. + * Check that all emulated MMIO ranges are correctly (in respect to their size + and order in the guest address space) mapped. + * Accept or reject an assigned TDI. +3. The device attestation module. Once the TDM has authenticated and verified an + assigned TDI, it can attest it through local or remote attestation before + finally accepting it. The TDM core fetches an attestation evidence through + the ABI plugin module and forwards it to the device attestation module. This + module then verifies the device evidence either locally or remotely, depending + on a guest-specific TDM policy, and returns an attestation results back to the + TDM core. + +### Device Detection + +### TEE ABI Plugins + + + +#### Plugin Interface + +A Rust trait called by the TDM core to interact with the TSM. +(Not needed if Linux provides a converged TEE userspace API. + +``` rust + + + +``` + +### Device Attestation + +## Theory of Operations + +### TEE-IO Acceptance Flow + +#### Detection + +#### TDI Security Attributes Check + +#### Device Attestation + +##### Local Attestation + +TDM is a Relying Party. +TDM to use part of the Attestation Service crates + +##### Remote Attestation + +## Glossary + +| Term | Acronym | Definition | +|:-----|:-------:|------------| +| Confidential Computing | CoCo | The protection of data in use by performing computation in a Hardware-based TEE. +| Confidential VM | CVM | A confidential computing virtual machine. Same as a TVM. +| Device Security Manager | DSM | A DSM is a logical entity on a TEE-IO device that enforces the TDISP security policies, attributes and states. +| Integrity and Data Encryption | IDE | Extended PCIe capability for integrity, confidentiality and replay protection of PCIe Transport Layer Packets (TLP). +| Security Protocol and Data Model | SPDM | A DMTF defined specification for exchanging messages between devices over a variety of transports and physical media. SPDM is used to exchange TDISP and IDE Key Management messages over PCIe DOE mailboxes. +| TEE Device Interface Security Protocol | TDISP | An architecture for trusted I/O virtualization. +| TEE Input and Output | TEE-IO | A PCIe-defined conceptual framework for establishing and managing trust relationships between a PCIe device and a TEE. +| TEE I/O Device Interface | TDI | The unit of assignment for a trusted I/O capable device. For example, a TDI can be a Virtual Function (VF) or a Physical Function (PF). +| TEE VM | TVM | A VM instantiation of an confidential workload. +| Trusted Device Manager | TDM | A confidential guest TEE-IO device manager, responsible for verifying, attesting and accepting CoVE-IO devices into a TVM TCB. This is a TVM guest software stack component. + diff --git a/tdm/src/main.rs b/tdm/src/main.rs new file mode 100644 index 000000000..e7a11a969 --- /dev/null +++ b/tdm/src/main.rs @@ -0,0 +1,3 @@ +fn main() { + println!("Hello, world!"); +}