 Hi, I'm Ajun Nakajima. We are working on TE-IO support, Trusted Execution Environment IO, where we can assign a device or device interface to trusted VMs. Today, we are presenting device attestation for confidential computing. This is the first step for the TE-IO. As I'll explain later, today, direct IO is not available for hardware-based TE-VMs, for example, TDX-VM. And I'll cover the first part of the introduction, and Joanne will cover most of the presentation. This is just the discrimers. First, I'll talk about IO virtualization in a virtualization-based trusted execution environment, TE, showing the types of configurations and use cases. I'll also talk about overview of architecture for trusted VMs with TE-IO to show how the device attestation is positioned in a big picture. I have a presentation tomorrow to talk about more details of the architecture and then implementations. So this table shows how physical devices are used in a TE environment. The first one is a trusted device. Obviously, such a device is not included in a TCV of a trusted VM. We cannot use that device directly assigned to the guest. And I'll talk about more details later. The second one is a trusted device. But still, we need to use a bounce buffer. I'll talk about details more. So let's go into the more details on the next page. Before that, currently, we have only one. We are seeing some use cases of two, but we haven't seen three yet. So this is the first one, untrusted device, and that device is not visible to the trusted VM. Instead, guests will see synthetic devices, such as VRTIO. And in that case, we cannot use that low data. And then the data needs to go to the shared memory or unprotected memory. So we need to copy the TVM, need to copy out or copying in the data. And then the device needs to do DMA against the shared memory. And then the device will see only encrypted data. To protect the data, the TVM needs to encrypt or decrypt the data when do the IO. So in this case, no direct IO. And notice there are two sides of an overhead. One is copying, copy out the data like this. And then encryption, decryption to protect the data or integrity of the data. And this model works when the device doesn't consume the data for computation. For example, like a network storage, we can send encrypted data to a network, like a TLS. Or the encrypted volume, we just create encrypted blocks. So this case is actually the most common case of the use cases today. Next one is the direct IO assignment. So let's say the TVM can trust the device in some way. Then assign the device to TVM. However, if the device doesn't share the key, then it cannot do direct IO to the TVM. Even if the device and then TVM share the key for the encryption, decryption, if the underlying data link is not trusted, then the TVM still needs to use the shared memory, like the type 1. And then also IO MME and then MMI are still managed by the BMM. So if a BMM is not trusted, there are some risks for the TVM. For example, MMI is used for the TVM to access device interface registers, such as command registers of the device. And it's possible that the BMM can set up mapping to a wrong device, for example. So there are such cases there, as long as the BMM is not trusted. Now this is the summary of physical devices in the TVM environment. As we saw, the first two both require bounce buffer, where the TVM needs to copy in, copy out, combined with the encryption. The first case, the TVM itself needs to decrypt and encrypt the data for the protection of the data. Second case, the device also needs to do that. The difference between the first and the second one is the device needs to consume the data for the computation. For example, GPU or FPGA, they need to consume the data. And if the data is encrypted, then it also needs to, the device also needs to encrypt the decrypt. Okay, so to minimize such overhead, we need to have direct assignment of a TEIO device. So that's our goal. So next I'll talk about how we can do that. Okay, so this is the new spec, it's called the TD-ISP, Trusted Device Interface Security Protocol. This is an architecture defined by the TD-ISP. I'm not going to talk about the details of this architecture, because I'll be presenting this in details tomorrow, as I said. But I'll just explain the minimal part of this one for this presentation. One important entity in this picture is TSM. TSM is a T Security Manager. It's a logical entity, and it's trusted, it's a part of a TCB of the all TVMs. Okay, and then on the device side, this is a device, single device. If you look at this device, we have physical function, TDI is the device interface, TE device interface. And it has a state that's defined by the TD-ISP. Also on the device side, there is a logical entity, which is device security manager. And TSM and DSM communicate each other using secure channel. So the challenge for the trusted devices is how that communication, especially the TSM and then DSM can communicate in a secure fashion. Another question is, how TE trusts the device? And Joanne will talk about more details on those subjects. Let's see how the device attestation works in a confidential computing environment. As Joanne mentioned before, we have two challenges need to resolve. The first one is that how the TE communicates with the device to get the device information. Since the TE is known as a TVM, it runs on top of VMM. The VMM may hijack any communication between the TVM and the device. As such, we need to establish an authenticated secure session between the TVM and the device. Here is the TE device communication model. There are two types of communication channels between the TE and the device. The first one is the management channel. Usually it is a software based. You can see that in the middle of the picture, there is a big yellow arrow between TSM and DSM. The TSM and DSM may use SPDM as a communication protocol. The SPDM protocol is standardized by the DMTF organization. It stands for secure protocol and data model. You can treat the SPDM protocol to be a lightweight network TLS. It supports secure communication between two endpoint devices on one platform. By using SPDM, the host TSM can get the device certificate and the device measurement in a secure manner. The TSM can set up an authenticated secure session with the DSM. Based upon that use case, it can be either one-way authentication or mutual authentication. The SPDM protocol is a transport layer similar to the TLS. It allows application protocol using SPDM secure session. The second usage of the management channel is to negotiate the data communication. Encryption key. The keys can be transferred by using SPDM application between the TSM and DSM. In the TEIO device use case, the PSAC standardized the IDE key management protocol. The IDEKM is secured by the SPDM session. The TSM and the DSM negotiate IDE stream encryption key and set the key to the hardware for data transfer. In the TE device use case, the device driver in the TVM may negotiate the software data encryption key with the device in SPDM session. The software data encryption key can be used to encrypt or decrypt the data in the bounce buffer. And you can see that in the bottom of the picture, there's a big yellow array between the host CPU, SOC and device hardware. And that is the hardware IDE session. The third usage of the management channel is a TDI interface management. The PSAC defined a TDI SP protocol to allow the host TVM and the VMM manage the device interface. For example, the VMM may assign one or more specific device TDI to one TVM. Then the VMM need to lock the device configuration. The TVM need to send the TDI SP start interface command to allow the device perform DMA access, etc. This is shown on the top of the picture. TDI one is assigned to TVM one, while TDI two is assigned to TVM two. The drone will discuss that topic tomorrow. Once this management channel work is done, the TVM and the device can transfer the confidential data via data channel. In the TEIO device use case, the standard PSAC IDE stream can be used to protect the data communication via hardware DMA. While in the TE device use case, the data in the bounce buffer can be encrypted by using the key to negotiate in above steps. The second challenge is that how a TE trust the device. First, the TVM verify the physical device identity and the device version. The identity is usually presented as device X.59 certificate chain. The device version can be presented as the device firmware measurement or secure version number SVM. Those information is static info. The verifier should have some golden value as policy and manifest. You can pair with the data from the device with the manifest according to the policy. This step is also known as device attestation. Second, the TE need to verify the device interface information. For example, the interface capability and the configuration. Some of them is device dynamic data configured by the VMM such as an MMI address. As such, there's no golden values. The device driver need to perform some check. This figure should a typical attestation architecture. The TSM act as a tester. It use SPDM protocol to collect the device certificate chain and the measurement from the device DSM with security guarantee. The TSM only verify the integrity of the information. For example, every certificate in the certificate chain should be signed correctly by the previous cert to the self-signed root cert. And the LEAF certificate is used to verify the digital signature from the device in a secure session establishment. The measurement data is also transferred in a secure session. However, the TSM does not know the policy. As such, the TSM do not know which cert or measurement is acceptable or not. Data, TSM present the device certificate and the measurement information to the TVM as evidence for the device. Then the TVM can perform some local attestation. The TVM collect the endorsement from the endorser. For example, the device root cert. The TVM collect the expected golden value as the reference integrity manifest ring from the device manufacturer. Then the TVM use the defined policy to check the device certificate chain and the device measurement. The policy could be very strict. For example, only one specific device measurement from the device can be accepted. Such as the latest one published by the device vendor. Or the policy could be flexible. For example, the TVM accept the specific device secure version number SVN. As long as the device has this SVN, any other firmware measurement can be accepted. Or the policy could be a partial match. For example, the device may provide different measurement for code and configuration. The policy can say as long as the measurement for the code matches the device is accepted. The device measurement for the configuration can be ignored. Or in order to define the policy is out of scope of any standard as far as we know. The tenant owner can make their own decision. Besides local attestation, the TVM may support remote attestation for the device. In this case, the verifier is from remote. The TVM need to record all data such as device evidence, verification policy, ring and endorsement to the TVM measurement register and the event log. Then the TVM present those information to a remote verifier. Then the remote verifier may use its own endorsement, ring and policy to verify if the TVM is trusted. In the figure, we use the item name underscore R to indicate the data for remote verification. And that is different with the item used in local verification. Once the physical device is accepted, the TVM need to verify the device interface. The device interface information is returned via T-DISP protocol, which is a application protocol in SPDM secure session. The T-DISP can return the device interface capability as well as the configuration. The configuration is known as the device interface report. The DSM manages the T-DISP protocol on the device side. The T-DISP capability is usually a global static data. For example, what is the device address width? Which T-DISP commands are supported? Which interface report is the TDI specific dynamic data? For example, if the TDI allows the runtime device firmware update, if the PCI Express ATS or PIS is supported and enabled, if the MSRX capability message control register status is, and what is the signed MMIO range? The TVM gets those information via T-DISP protocol with the protection and the TSM. The TVM can verify it if the TDI capability is accepted, then the TVM can check the TDI report to ensure the data is correct set by the VMM, such as the MMIO range. In the last section, we will discuss the implementation. In Intel TDX, the TVM means the static guest OS. The TSM is a TDX module as a policy enforcer, and the KVM is the resource manager for all devices. And this table shows the data need to be verified by the TVM. From the high level, there are two categories of data. One is a physical device-related data which is transferred via SPDM protocol, and the other is device interface-related data which is transferred by T-DISP protocol. The device identity information is the X.59 certificate chain. It is transferred via SPDM guest certificate command. The device measurement may include the measurement of the ROM, firmware code, hardware configuration, firmware configuration, device debug state, device boot mode, version, secure version number, etc. This information is transferred via SPDM get measurement command. The device also returns the SPDM capability, for example, if the device can return a fresh measurement or static measurement. It is from the SPDM get capability. Last but not least, when VMM launched the TSM to set up the SPDM session, the VMM can indicate some session policies. For example, what if the session combination policy for the ROM time firmware update? This SPDM policy information should also be sent to the TVM for verification. The device interface capability includes the supported T-DISP command list, the device interface lock flags, the device address width, etc. This is from the T-DISP capability command. The T-DISP interface report includes multiple dynamic information. The TDI configuration capability from the device, for example, if the memory attribute is updatable, the configuration setting from the VMM, for example, if the ROM time firmware update is supported, or the ROM time setting from VMM, for example, what's the MMI range address? In Linux, there are multiple ways to verify the data. For example, the verification code could be built into the TVM directly. The verification code could be based on some policy, and the policy data could be static built in the TVM or dynamic input at runtime. For example, the SPDM root certificate, the SPDM device reference integrity manifest should be the policy data. They should be determined by the tenant user. While the T-DISP MMI range verification should be the code, and the kernel driver should check no overlap and accept MMI range to VMM. Also, the verification could happen in kernel or user space. As we discussed before, the T-DISP MMI check should be in a kernel while the device data station better be in a user space since the certificate verification or device measurement match according to the policy. Finally, we will show the device initialization flow as an example. The box without border means the existing steps, and the box with blue border means the TE device-related steps, and the box with red border means the TE-IO device-related. In which the dark green means the steps in TSM, not TVM. The first, the VMM can inject the PCI hierarchy to a guest. Once the T-SET device is found by the TVM, it goes through the PCI device filter. The tenant user is allowed to set up a forbidden device list, and those devices are not allowed. If the device is allowed, the driver can check if it is a TE-IO device. If it is, then TVM gets the device information from the TSM. For example, the SPDM certificate or measurement via SPDM protocol, the device interface report via T-DISP protocol, then the driver will perform local attestation to verify the SPDM certificate and measurement according to the policy. It also verifies the TE-DI interface report. If everything is okay, the TVM can accept this device as a TE-IO trusted device. If the device is not TE-IO device, the TVM may continue to check if the TE device, since the TVM may transfer the confidential data to the TE device, the TVM also need to perform device attestation for the device, and then accept the TE device. Last, if the device is neither a TE-IO device nor a TE device, then it is just a normal, untrusted device. The TVM should not transfer any confidential data to the device. Once the device type is determined, the driver can continue the device process. To summarize our talk, a device in a TVM can be untrusted, a TE device or a TE-IO device, and the TVM need to perform device attestation for the TE device and the TE-IO device before using, because this device needs to access the TVM confidential data. The standard body defines the SPDM protocol and the T-DISP protocol, and they can be used to manage the TE-IO device. It is important that Linux guest kernel and KVM add such infrastructure support. Tomorrow, Joan will talk the device IO in a trusted execution environment with more detail. And here is the link of the standard related to our talk, like SPDM, secure SPDM, PCI-related DOE, CMA ID, T-DISP, or some device related information. And thank you very much for your time.