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 CoVE with efforts to improve the developer experience? I hope we see common abstractions across different TEE architectures!!!
I agree with your point, we need common abstractions across different TEE architectures!
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.
Can you explain what the relationship is between this and CoVE? Is ACE (this repo) the firmware, and CoVE the RISC-V hardware extensions that it requires?
How does it run on a P550 if that doesn't support CoVE?
Yes, that's basically the relationship between CoVE and ACE, from a quick glance. In this case, ACE is simply implementing a formally modeled and verified security monitor where the design has been extracted to Coq and the invariants proven.
It can work on P550 because CoVE supports several "Deployment strategies", the one ACE uses is referenced in the README: CoVE spec, Appendix D, "M-mode [Trusted Security Manager] based deployment model" https://github.com/riscv-non-isa/riscv-ap-tee/blob/main/src/... -- the other appendicies detail e.g. Smmtt based designs, and apparently there's a not-yet-written "Nested Virtualization" design in Appendix C.
They also note that the P550 isn't a "true" port due to the preliminary, non-ratified H extension, and it also misses another required extension called "Sstc" but they just emulate it. (Sstc is interesting; it seems to be a performance optimization for delivering timer interrupts directly to supervisors, but I can imagine in the case of CoVE timer interrupts going through M-mode could leak data, making it more of a security issue.)
Leveraging M-mode is basically how previous security monitors like keystone worked too, back on the original HiFive Unleashed. It just sorta treats M-mode as an analogue to the "secure world" in ARM parlance, though there is no requirement that M-mode has e.g. an encrypted memory controller and dedicated memory region, and I'm guessing other things (I'm not super familiar with TrustZone.)
Broadly speaking this reminds me as a kind of a evolution/combination of Microsoft's Komodo (formally verified, but was only for e.g. SGX-style enclaves) and existing M-mode TEE systems like Keystone -- but upgraded to support "Confidental Computing" virtual machines. So that's quite nice.
The CoVE specification defines a unified confidential computing architecture for RISC-V that scales across embedded, edge, and cloud use cases. The system designers select the appropriate deployment model based on the specific constraints and goals of their target systems. ACE adopts the deployment model tailored for mid- to high-end embedded platforms (see Appendix D in the CoVE spec).
Ultimately, we should expect multiple CoVE implementations optimized for different domains. For instance, in cloud environments, the focus is on maximizing performance and resource utilization—typically requiring full CoVE support and advanced hardware features such as Smmtt and AIA. Salus from Rivos is an example of such a high-end implementation. In contrast, embedded systems have limited power and silicon budgets, and thus prioritize simpler hardware. These systems trade off performance and accept memory fragmentation in favor of reduced hardware complexity and cost—ACE is designed with this trade-off in mind.
ACE runs on P550 by emulating the missing hardware features. This enables experimental deployment on real hardware. (P550 is the first commercially available RISC-V processor with virtualization support.)
(1) ACE leverages hardware virtualization support, including an MMU, to enable confidential virtual machines. In contrast, Keystone is designed for simpler processors that rely on just machine/supervisor/user privilege levels and physical memory protection (PMP), making it more suitable for process-based enclaves—similar to architectures like Komodo or Intel SGX. In that sense, ACE is conceptually closer to Intel TDX, but tailored for a different domain: embedded systems rather than cloud infrastructure.
(2) In ACE, the architecture and code are simplified to facilitate formal verification.
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 CoVE with efforts to improve the developer experience? I hope we see common abstractions across different TEE architectures!!!
I agree with your point, we need common abstractions across different TEE architectures!
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.
Can you explain what the relationship is between this and CoVE? Is ACE (this repo) the firmware, and CoVE the RISC-V hardware extensions that it requires?
How does it run on a P550 if that doesn't support CoVE?
Yes, that's basically the relationship between CoVE and ACE, from a quick glance. In this case, ACE is simply implementing a formally modeled and verified security monitor where the design has been extracted to Coq and the invariants proven.
It can work on P550 because CoVE supports several "Deployment strategies", the one ACE uses is referenced in the README: CoVE spec, Appendix D, "M-mode [Trusted Security Manager] based deployment model" https://github.com/riscv-non-isa/riscv-ap-tee/blob/main/src/... -- the other appendicies detail e.g. Smmtt based designs, and apparently there's a not-yet-written "Nested Virtualization" design in Appendix C.
They also note that the P550 isn't a "true" port due to the preliminary, non-ratified H extension, and it also misses another required extension called "Sstc" but they just emulate it. (Sstc is interesting; it seems to be a performance optimization for delivering timer interrupts directly to supervisors, but I can imagine in the case of CoVE timer interrupts going through M-mode could leak data, making it more of a security issue.)
Leveraging M-mode is basically how previous security monitors like keystone worked too, back on the original HiFive Unleashed. It just sorta treats M-mode as an analogue to the "secure world" in ARM parlance, though there is no requirement that M-mode has e.g. an encrypted memory controller and dedicated memory region, and I'm guessing other things (I'm not super familiar with TrustZone.)
Broadly speaking this reminds me as a kind of a evolution/combination of Microsoft's Komodo (formally verified, but was only for e.g. SGX-style enclaves) and existing M-mode TEE systems like Keystone -- but upgraded to support "Confidental Computing" virtual machines. So that's quite nice.
The CoVE specification defines a unified confidential computing architecture for RISC-V that scales across embedded, edge, and cloud use cases. The system designers select the appropriate deployment model based on the specific constraints and goals of their target systems. ACE adopts the deployment model tailored for mid- to high-end embedded platforms (see Appendix D in the CoVE spec).
Ultimately, we should expect multiple CoVE implementations optimized for different domains. For instance, in cloud environments, the focus is on maximizing performance and resource utilization—typically requiring full CoVE support and advanced hardware features such as Smmtt and AIA. Salus from Rivos is an example of such a high-end implementation. In contrast, embedded systems have limited power and silicon budgets, and thus prioritize simpler hardware. These systems trade off performance and accept memory fragmentation in favor of reduced hardware complexity and cost—ACE is designed with this trade-off in mind.
ACE runs on P550 by emulating the missing hardware features. This enables experimental deployment on real hardware. (P550 is the first commercially available RISC-V processor with virtualization support.)
> ACE supports local attestation, a mechanism to authenticate confidential VMs intended for embedded systems with limited or no network connectivity.
I'm interested to know the safe definition of 'limited' connectivity - is there some kind of boundary which logical reasoning can't support?
How does this differ from Keystone?
There are two key differences:
(1) ACE leverages hardware virtualization support, including an MMU, to enable confidential virtual machines. In contrast, Keystone is designed for simpler processors that rely on just machine/supervisor/user privilege levels and physical memory protection (PMP), making it more suitable for process-based enclaves—similar to architectures like Komodo or Intel SGX. In that sense, ACE is conceptually closer to Intel TDX, but tailored for a different domain: embedded systems rather than cloud infrastructure.
(2) In ACE, the architecture and code are simplified to facilitate formal verification.