 Hello, my name is Hau Wu. I'm from Intel Virtualization Enabling Team. Exploring IO support for virtualization-based trusted execution environment is my topic today. Here is today's agenda. First of all, a short introduction for the background and then move to the first part of this presentation which describes current direct IO support for TE virtual machine, including working model and the challenges. After that, we will talk about the TDI support which is a new option for trusted IO inside TVM. In this part, we'll give some overview for PCIe, TE device interface security protocol, TDSP spec, then introduce TE IO support for Intel trusted domain extensions, TDX, and summarize the last part. Background, virtualization techniques are used to provide increased security guarantee for trusted execution environment, TE, such as TE virtual machine. And from TE virtual machine point of view, the VM is not trusted. Confidential computing inside the TVM requires IO support for example, assistance or accelerations provided by external devices. Today's presentation will only focus on direct IO support discussion. For on this page, we will start to talk about the current TDIO solution for TVMs. Current limitation is that devices are not in the trusted compute boundary TCP of the TVM. So devices are not allowed to read and write the TVM's confidential memory. So it requires to move TVM data from private memory to share memory first of all. As TVM data in private memory is protected by encryption, so the cryptocopy in and the cryptocopy out are required to move TVM data to or from share memory. But there is no protection for data inside share memory and it can be accessed by VM. We cannot put a plant text data into share memory. Another point is the data pass between host and the device is not trusted. IMU is not in the TCP and the physical link is not protected. So from this figure, additional protection must be applied to the real pass. The right side figure shows the working model for current direct IO solution. Actually the TVM data can be consumed by either device or remote pair. So there are two cases, case one in read and case two in blue. But anyway, secured data channel must be established to improve data confidentiality and integrity. As you can see, separate text data is transferred to share memory and the data pass to device. Challenges as current architecture and the working model requires additional cryptographic and protections, just brings additional complexity. And we will have a significant performance overhead as the extra steps needed for equipped to copy out and equipped to copy in to from share memory. Is it possible to have some security mechanism to allow TVM to include the target device into its TCP? So that a target device can access private memory directly to avoid the performance overhead by extra copies to file share the memory. The answer is yes. There is a new option we will discuss in the next part of this presentation. TTISP is a new option we would like to discuss. First of all, I would like to introduce what is the TDI-SP. TDI-SP is PCIeT device interface security protocol. It defines architecture of trusted and virtualization. We also can use this TIO per TDI-SP spec. It provides below key functions. The establishment trust relationship between TVM and TDI-SP compliant device. We will show what is TDI-SP compliant device in later page. Help secure the data path interconnected between the host and the device as the tag may come from the physical link. Support the TDI-SP compliant device assignment and the removal lifecycle in a trusted manner. Whereas TDI-SP support TDI-SP compliant device can be trusted and accepted into the TVM's TCP. TDI-SP builds upon the foundation provided by below technologies. I would like to give a short introduction before we move to the architecture page. DMTF security protocol and data model. SBDM. SBDM defines standard messages, data objects, and the sequence for performing message exchanges with device. The message exchanges include authentication of device identities, measurement, and also session key exchange protocol to enable confidentiality with integrated protected data communication and other related capabilities. PCIe, compliant measurement and authentication CMA defines option or security features based on the adaptation of the data objects and the underlying protocol defined in SBDM spec. Allegedly and the data encryption IDE provides confidentiality, integrity, and replay protection for translation layer packets, TLPs for PCIe device. Data object exchange DOE defines one mechanism to perform data object exchange with a targeted device. DOE provides a transfer layer for SBDM messages exchange with targeted device. This is the TDI-SP hosts device reference architecture defined in TDI-SP spec. In this figure, one TIO capable device can host multiple TDIs. TDI is the device interface the unit of device assignment defined in TDI-SP spec. TDI can be an internal device, no IOV device, a PF or a VM. In the left side, we can see VM, PF drivers are not trusted, so they are not in any TCP. And one TDI is assigned to legacy VM and same time two more TDIs are assigned to TVM separately. TDI-SP not only require device to host the TDIs, but also requires device to implement the device security manager DSM, which is a logical entity in the device to enforce security isolation. It provides below functions, including authentication of device identities and the measurement reporting per SBDM. IDE encryption keys configuration. As IDE keys, green keys are used to protect the TOPs for the links, so it requires to send the IDE keys to your device. Before IDE security manager DSM can send green key, it requires SBDM session for protection. The IDE key measurement messages are protected by SBDM session key, the orange key. TDI management, TDI-SP has defined the security states for TDI, unlock the locked run and error. In order to manage TDI states, it requires TSM to send TDI-SP messages to DSM. And the TDI-SP messages are protected by SBDM session key too. But before the TDI is in a locked state and VM host driver can configure it and use it or even assign it to legacy VM. Once we decide to attach TDI to a TVM, then we need to lock the TDI configuration. And allow TDI to report configuration and other device identities to TVM for attestation. Once TVM decides to accept the device, TVM also need to move TDI from locked state to run state which is the only operational state for trust MMO and TMI. Access control for MMO and DMA, security mechanism to isolate TVM data are required too. This page where we'll talk about TSM which is the TE security manager. TSM needs to enforce security isolation for TVMs and manager security states for TDIs. TSM and security mechanisms and enforce access control for both direction trusted DMA from TDI to TVM and also trusted MMO from TVM to TDI is a host site. As you can see in this figure, the translation into TA which helps with access control is in the TCB of all TVMs as it is enforced by TSM. Similar as TA, IDE host site is enforced by TSM too. So IDE is in the TCB too. Another key concept introduced by TDIP is trusted MMO and DMA. In case IDE is used, there is a TBIT in TLP IDE prefix. It is used by originator to indicate that this TLP is associated with TVM. Both device and host translation agent can use this TBIT to perform access control. After the quick overview of the TDIP from this page, we will talk about the TDIP TDIO support of Intel TDIX. This architecture for Intel TDIX with TDIO support is consistent with TDISP reference architecture we discussed in previous slides. Same as existing TDIX architecture, VM is still the resources manager and the Intel TDIX module function as TSM provides new TDIX APIs to safely attach, detach TDIs to TVM. The new elements added on top of TDIX architecture are in the supported numbers. First one, TDISP compliant device. It requires device to implement one or more TDIs and also the TSM, which we already discussed in previous slide. Second one, IDE protection for the physical link. Not only device requires the IDE support but also root port for ISOC side need IDE too. Actually host driver and VM have no direct access to IDE hardware in host SOC side so only can request TDIX module while new TDIX APIs for IDE. Third one, trusted MMO and DMA support as we discussed in previous slides, trusted MMO and DMA are tagged with TPIT. Access control is performed based on that TPIT. Host side trusted PTAGOS for trusted MMO and DMA are managed by TDIX module too so more TDIX APIs are exposed for this purpose. Last one, to support TDIO, TDIX module needs to manage a lot of the new things including SVDM, IDE, TDI, trusted PTAGOS and access control. So more TDIX APIs are exposed to VM and TBM for this purpose. For SVDM implementation in TSM and architecture TD named as TPIT, TDIX information agent is introduced to upload the actual SVDM work for TDIX module. This page we are going to talk about the possible software touch points. We hope the software enabling for TDIO on Intel TDIX can take advantage of the general features like components in orange. Define the common layer and interfaces in support of TDISP components in yellow and also handle Intel TDIX specific implementation in blue ones. This figure shows the major software touch points with a circular number. Let me explain them one by one. When we expose device interface to the XMVM we can use VFL for TDIO case. We still can reuse the existing VFL framework but some additional work needed including identify capability of the device and additional TDISP initialization work. This can be done while common APIs provided by TDISP component, which is the second one I would like to discuss. It can provide the generic services for TDI management and also can help with SVDM-ID setup flow defined by TDISP spec. We expected SVDM and IDE can provide some common interface as they are generic features not only used in TDISP case but they do need some extensions to support TDISP model. For example, in TDIO case IDE support in root port is managed by TDISP module not kernel driver. So this is why we have TDIX specific code to interact with TDISP module to finish the task. Another thing is TDISP support needs to do is binding the TDI to the type in the TVM while TDISP module. As access control for trusted MMO, DMA and other security policies can be enforced by TDISP module. Trusted MMO and DMA support are considered as Intel TDISP specific changes on top of existing TDISP implementation. From QVM side trusted MMO will be managed by the security PT and in IMU side there is new TDISP mode for trusted address translation. Security PT is reused as IO applicable in current TDISP module design. Number four, PCI TDISP support inside TD. From TD user point of view, the TDI exposed by VM is a PCI device but TD cannot trust it unconditionally. After TD enumerates this device is TDI then TD needs to perform TDISP device attestation. During attestation the device identity measurement TDI state and configuration need to be verified. If everything is okay then TD can decide to accept the TDI. It will require TD to notify TDISP module to unblock the trusted MMO and DMA from host and also move TDI to operational state which is the raw state to allow trusted MMO and DMA from device side. Actually generic flow for TDI enumeration attestation and acceptance should be common but for each state it depends on TDX APIs provided by TDAS module. So we can see both yellow components for generic TDISP and the blue one for TDX specific implementation here. After TD accept the TDI then it allowed to bind with PCI device driver. But the device driver may need some extensions to kernel APIs to map trust MMO and allocate private DMA buffers. Okay, that's all for the software touch points to enable Intel TDX with TDIO. Summary for today's topic. I also thought it's important for computational computing inside the TVM. Current direct IO solution has limitations and performance overhead and the device can't access TVM's private memory. TDISP defines an architectural for trusted IO virtualization new architecture allows TDI to be accepted into the TVM TCP. Intel TDX with TDIO is designed to implement the TDISP architecture. Besides platform and Intel TDX module extensions software changes to Linux and KVM are also required, including common support for TDISP and specific implementation for Intel TDX. That's all for today's presentation. This is only a very high level introduction for TDISP and Intel TDX with TDIO. It doesn't cover details. So if you want to know more, you can learn more details from the reference documentations listed in the next page. If you have questions, you can ask directly after this video or send me emails later. Thanks for watching this.