As the industry has evolved to support the kinds of shared data centers described above, the concept of Trusted Execution Environments (TEEs) has arisen in virtualization. Here, the idea is that the owner of a Virtual Machine (VM) may not want to trust the Virtual Machine Manager (VMM) (sometimes called a Hypervisor) in the same way a physical server owner might not want to trust the datacenter personnel. Within a TEE, the VMM still controls resource management as in a traditional virtual environment, but unlike a legacy VM, a TEE Virtual Machine (TVM) can manage its own security. For example, the VMM may allocate certain encryptable memory pages to the TVM, but it’s the TVM that controls the encryption keys for those memory pages. On the CPU and memory side of the server, these controls are specific to the CPU and memory architecture in use, so no new specifications are needed to expose them to the VMM. When the concept is extended to an I/O interface like PCIe, it’s much more important to have an open framework that doesn’t require the VMM or TVM to have such specific knowledge of the devices being connected.
TDISP stands for TEE Device Interface Security Protocol, and it provides for three main functions:
1) Establishing a trust relationship between a TVM and a TDISP-capable device
2) Securing the PCIe path between the host and TDISP-capable device
3) Attaching/detaching a TDISP-capable device’s interface to/from a TVM in a secure manner
While much of this functionality resides in software (or firmware), the TDISP specification requires a number of different behaviors and PCIe features in TDISP-capable devices.
TDISP currently focuses on using Virtual Functions as defined by the PCI SIG Single-Root I/O Virtualization (SR IOV) specification, but notes that future revisions may be extended to other schemes. Physical Functions (PFs) are defined as PCIe Functions which include the SR-IOV capability structure and can therefore operate as the management entities for associated Virtual Functions (VFs). VFs were originally envisioned as lightweight functions which could be directly assigned to VMs, but which might rely on the VMM to emulate some aspects of their PCIe configuration space.