Skip to content

Commit

Permalink
tdm: Trusted Device Manager architecture definition
Browse files Browse the repository at this point in the history 
This is the initial commit for the Trusted Device Manager (TDM).
It only contains an architecture document, no implementation is provided
yet.

Signed-off-by: Samuel Ortiz <[email protected]>
  • Loading branch information
@sameo
sameo committed Aug 28, 2023
1 parent fe8fb1a commit 24f4767
Show file tree
Hide file tree
Showing 6 changed files with 284 additions and 0 deletions.
1 change: 1 addition & 0 deletions Cargo.toml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@ members = [
"confidential-datahub/secret",
"image-rs",
"ocicrypt-rs",
"tdm"
]

[workspace.dependencies]
Expand Down
3 changes: 3 additions & 0 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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)
11 changes: 11 additions & 0 deletions tdm/Cargo.toml
View file
Original file line number Diff line number Diff line change
@@ -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]
4 changes: 4 additions & 0 deletions tdm/README.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
# Trusted Device Manager

The Trusted Device Manager (TDM) is a confidential guest component for handling
trusted IO operations.
262 changes: 262 additions & 0 deletions tdm/docs/architecture.md
View file
Original file line number Diff line number Diff line change
@@ -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.

3 changes: 3 additions & 0 deletions tdm/src/main.rs
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
fn main() {
println!("Hello, world!");
}

0 comments on commit 24f4767

Please sign in to comment.