 My name is Justin He, and I'm currently working with the ARM container team as a technical leader. Today, I'm so excited to discuss a topic for the Linux security summit 2023. The topic is when combination containers meet ARM CCA. Is the cocoa ready to embrace the CCA? I hope we can answer this question at the end of this section. I will be instructing my presentation into five main parts, which are as follows. A background introduction to provide you a better understanding of the topic. Next, I will provide a review of cocoa, which is a key technology in the development. Next is the arms and combination container solution. In this section, I will discuss the work about what ARM is doing to build such a solution, as well as some extended projects related to this work. The fourth one is the current status, including the progress of the CCA and the cocoa arms. The last sequence is the demo section. I will conclude my presentation with a series of demos to showcase the capabilities and benefits. Let's begin with the background to the topic at hand. I plan to say a few words about the strong confidential computing trends nowadays. As you can see from this table, we can conclude that confidential computing is a hot topic in many leading companies. But most of the existing projects, either commercial products or open source rappels are specifically tied to internal AMD architecture. Fundamentally, ARM also needs a solution to standardize the confidential computing consumption at the container level. In order to reduce the time to market, when the silicon is ready, CCA can be seamlessly deployed as soon as possible. That's the reason why we want to get involved in the project. Now let's turn our attention to cocoa overview. Cocoa is a project to standardize the confidential computing at the past level, container level, and simplifies its consumption in components. There are many contributors from many leading companies. Inside this project, there are a few design rationales. For example, the host software stack must not see or tamper with the container. The unmodified containers are needed to transparently deploy it as previously. The CSPs should be removed from the TCP, trusted computing base. And it also aims to support multiple TEs, including CCA, to protect the container and the data. It's worth mentioning that in different architectures, the TCP might have different TCP boundaries. For example, in CCA, the firmware should be trusted. And so I draw this box with red and blue stripes. Let me break down the design aspects of cocoa into a few major components. Firstly, the Kubernetes operator for cocoa includes a dedicated operator, which essentially is an operator for deployment and configuration. And we should introduce the new CC runtime to support the arc-specific runtimes. They also feature a customized version of container D to support special container image APIs. The second part is about the changes to the cutcontainer. Cocoa modifies the cutcontainer to manage the VM-based container lifecycle. It translates a set of VMM APIs and the cut configurations to enable the memory protection and CPU-register status in confidential guests. Additionally, it blocks some previous APIs that would access, I mean, read or write data from or to the container. The third part is the guest firmware. The runtime attestation inside the guest firmware should be enabled. That involves the guest firmware implementation. Cocoa enables some lightweight alternative to replace the heavy VFI SDK 2. Cocoa attestation, data protection or encryption alone is not enough so we should consider attestation. Cocoa also ensures that the owner verifies where, what and how it is surrounding the environment, whether the software stack and hardware platform are expected and eventually it will fetch the keys after attestation to decrypt the container image. The last part is about the container image service. Finally, Cocoa moves the previous operations on the host to the guest entirely, such as pool, decrypt, verify, mount and store. That is called service offload. It guarantees that all of the encryption, decryption, and signing verification are inside the TE. Here, I would like to summarize on the benefits of Cocoa for all. Firstly, Cocoa is focused on the past level user kits and it offers native multi-hack support. It's built on the production-level ready-cut container project, which makes it a reliable and stable option for container deployment. Anyway, to support Cocoa on ARM, ARM needs to modify every component of Cocoa here. This is where cooperating with a community provides an advantage. Cocoa leverages the existing components and the community efforts to provide an end-to-end solution for deploying containers in hardware TE. This includes support for a long time and firmware, attestation from a framework and also Kubernetes orchestration. Using Cocoa, ARM can save time and resources in deploying their own solutions. First of all, Cocoa has already been endorsed by many major players in the industry, including CSPs, Silicon Winners, and OS vendors. This indicates a high-level trust and confidence in the technology. Lastly, Cocoa is also an excellent reference solution for the deployment of containers on ARM, CTA, by developing and integrating the virus in house components such as the Kolo KVM, IMAM UEFI, and TFA, also the Verify Verizon. ARM can further optimize and enhance its solution. Next, I will show how we plan to implement the Cocoa solution on CTA. What's the rationale point of CTA? In short, CTA is very similar to MDSEV and Intel TDX hardware feature. The hypervisor manages the resources of a real machine but cannot access those resources, including the CPU registers memory. I mean, guest memory. Guest memory is protected in two ways. First, there is isolation. That means it managed to access the results in the fourth, one set of problems. Another one is encryption, mainly for reboot attacks. The IMAM is a EO2 implementation inside the real state. It exposes two interfaces. The first one is IMI, which provides the service to the host, the host software for the creation, management, and acceleration of the realms. The second one is the ISI, which provides the service to those software inside a realm for the management of the resource allocated to it. So what's the iMemory responsibilities? For example, it manages the lifecycle and realms, manages the realm memory with manipulating the state to two translation tables. It measures the initial state of the realm and allows the realm to request a measurement allowing for attestation. It also manages the context switch between the realms, the CPUs. The EO3 monitor is a TFA monitor supporting the FE feature IME extension. Essentially, it provides the management of GPT, a granular protection table controls the assignment of the memory to a physical address space. There's also a attestation ROT, a root of trust, located in the hardware, essentially a TFM core called ISSS. ISSS is the reference implementation of HES. Next, I will replace some of the components with those involved in COCO to provide a clear understanding. The COOPNES, the Catastrium V2, and the BMM, including CUMUL and the Cloud High Finder. It should be noted that currently COOPNES is considered utilizing the keyword. So what's the software impact on the realm guest and also the host? For the realm guest, the guest kernel enlightenment to support the ISI and the in-realm firmware that is against the firmware also should be changed and it provided the support to sharing the memory with the host and also provided the measurement and attestation. With regard to the host impact, the host kernel KVM supports with the IME and there's no impact to the host firmware when I'm about to load it. So this is what the confidential container solution would look like on ARM. A little bit complicated. Only a rough idea is needed and I will give you the details later. The red box means to offering confidentiality guarantees by using the hardware level features. The blue one means the resources managed by the host and they are used to run the container. The green ones belongs to the tenacity. They are the confidential areas carved out of the host but not visible or no accessible to it. The other boxes are the remote reliant parties. So here as you can see the highlighted boxes, I expect what we plan to do into five parts where ARM can contribute to enhance our enabled CTA features. I will elaborate more on the subsequent slides. The first part is the Kubernetes Cocoa operator. The operator is an extension introduced to manage the confidential resources without changing the Kubernetes itself. Now in our plan, we want to enable the parity features as X86. We also want to introduce the new CC runtime and provide a multi-arc support for a few features, a few images. We also will initiate a solution based on CCA by, based on the Kubernetes operator for CCA. The part two is about to change the cut around time lifecycle. This is the previous flow, simple and very straightforward. That is the previous flow before we enable the CCA. Then here is the update to the flow for CCA highlighting the problem. The owner tricks a poor image command as previously. The confidential continuous runtime on the host starts a VMDE in CCA. In the CCA case, it is a VM. Then the cut agent or the test agent performs the remoteization to the rely party and got the keys required to verify and decrypt the container image. Then dog downloaded the image and decrypt the image and starts the image as Juju. So we will be implementing the POC of Cata API or configuration changes for CCA to use QML to start a VM guest. We also plan to provide the cloud hypervisor changes for the attestation part in Cata agent or attestation agent. We also plan to implement the corresponding interface specially for CCA. Part three, as per the remote attestation procedures last for short, the architectural specification. The community proposed a key broker service KBS and attestation service is KBS implements the rely party and attestation service implements the verify. Essentially it is a verify proxy on ARM because it will communicate to remote verify variation and behave as a proxy. Another component for the key policy and key management connecting to the KMS generally provided by the CSP. The whole architecture aligns well with the REST background check model. Just like a company uses to verify that individual is who they claim to be. The employee as a tester provides the claims about education or previous experience. The employer rely party will contact to the organization verify to validate the claim that is the education worker experience. The attestation agent in the TEE sends a request to the KBS that the KBS will decide whether the attestation is needed. If it is needed KBS will reply a challenge to the attestation agent. Then the agent will send the evidence to the KBS. KBS will relay the evidence to AS for the verification. AS will reply the attestation result to the KBS after the verification is finished. If the results are verified by the KBS for example it has passed to execute the corresponding resource key fetching operation and sends it to the attestation agent. Here we plan to integrate Verizon into the verified part of the KBS. We also need to adapt the Verizon communication API between the components. To enable the whole attestation process on ARM we need to also need to implement the verify driver and attestator driver which are the ARC specific. The UFIE2 team provides a secure boot for loading CCA guest kernel and runtime service. It plays a key role in the measurement and attestation. It also provides the boot information injection essentially is a block of non-secure memory created by the host or booting memory passing and activating the realm. Typically it can be used to pass some secret for example key. Here is the evolution diagram on the Intel X86 for the guest firmware and its parity for the ARM what we call the in-realm firmware. TDIVF is a sub-package set special for TDX guest and TDShim is written by the Rust. Hamilties do want to unify different architecture guest firmware to a common implementation what is called a CCShim. Our plan is similar. First they abstract to the necessary and the minimum libraries from UEFI to support the realm guest boot and then relight the guest firmware by Rust language and at last we will merge the new guest firmware implementation into CCShim. This additional part is ARC agnostic and out of ARM scope now. Justin made it clear enough to understand. There are many keys in Cocoa project. Let's focus on the keys of encryption and decryption for the container image. This is the key management flow looks like. The owner will encrypt the container image and push the image to the remote registry. Also, specifically speaking, the owner will first dynamically generate a random symmetric key and encrypt the container image with the symmetric key. And the second step is encrypt the symmetric key with the owner's key. For example, private key so-called the wrapped key. Then the third step is to write the wrapped key into the container image and manifest as the content of a notation of the container image. So then the owner will let the trusted service, for example, KMS to manage its private key. The agent will agent inside the TE will pull the image inside the VM and start the attestation after completing the attestation. And if the attestation is passed, the agent will get the decrypted key from the relying party. And if everything is fine, the container will be decrypted and started as normal. So what's the current status of Cocoa and CCA? Regarding to the Cocoa project, the initial date and our purchase for cut containers supporting the real guest booting and the Cocoa attestation are in the internal review. And in terms of for CCA software and firmware status, here are the list of the patches, including IMM, kernel, QML, EDK2. The CCA extension faster model has been released. Here is the roadmap of Cocoa RR. Currently we are working on the first demo faster model and the CCA attestation enablement. Our future plan for Cocoa was several exciting parts here. So following that, we have the demo section. To several times, I made the demos in another video. So you can watch the video in another. The presentation, including three videos demos, showcasing the creating features of the cut containers in CCA enabled faster model. The first one is to start the cut container, direct boot via QML. The second one is compared to memory protection feature for cut container, like write something in the guest memory to verify whether the host or provider can access the guest memory. The third one is to start the cut container with the guest firmware boot, EDK2. So that's the snapshot. We got the evidence from the D-Message and the QML parameter list. So let's review the outline of the talk today. Nowadays, there's a strong trend towards the computational computing. After discussion with the community, we have been keeping Cocoa requirements aligned well with the CCA model. So it's time to start building an E2E reference solution for ARM CCA. It will be better to get involved in the extended projects to enhance the Cocoa. Under the roadmap of Cocoa, ARM CCA has been drawn up and everything is on the track. So let's come back to the question in the subtitle. Is Cocoa ready to embrace CCA? I think the answer should be yes. We are under the way. Finally, if you have any additional inquiries or questions, please do not hesitate to reach out to me at MelVox here. Thank you for your time. That's all.