Developers have faced in the confidential computing space, particularly with x86 TEEs, fragmentation leading to vendor lockin and a difficult developer experience due to multiple, somewhat incompatible standards/approaches. Does the CoVE effort, and IBM's involvement in it, aim to prevent a similar situation in the RISC-V world, fostering a more open and standardized TEE ecosystem? Are you using CCC to align RISC-V C…
The CoVE specification addresses fragmentation in the RISC-V ecosystem by defining a unified confidential computing architecture that scales across embedded, edge, and cloud use cases. Higher layers of the software stack, for example Linux KVM and QEMU, implement the defined ABI, enabling support for a variety of CoVE-compliant implementations. Currently, there are two CoVE implementations: ACE, targeting embedded systems, and Salus, aimed at cloud deployments. Additionally, there are efforts underway to port OP-TEE to the CoVE architecture.
Within the Linux kernel, there is ongoing work to unify internal interfaces across different TEE implementations (x86,ARM,Z,PowerPC) and harden the guest kernel. The CoVE patches are designed to align with these abstractions, though they have not yet been upstreamed. Remote attestation is still the pain point, since the CoVE spec proposes formats that are not compatible with Intel/AMD/TPM style. On the other hand, the ACE's local attestation re-uses the format from OpenPOWER PEF and opens it with versioning to new algorithms and properties.
From an end-user standpoint, VM-based TEEs are more agnostic to the underlying hardware technology compared with process-based TEEs, as they rely on the virtualization boundary for isolation. What does still change is the guest kernel and its supporting libraries, which must be adapted to leverage platform-specific attestation mechanisms.