You can have a look at this project that shows how with proper abstractions you can minimize unsafe Rust for low level firmware. Specifically look for page token, page allocator and page table implementations: https://github.com/IBM/ACE-RISCV
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.
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.
This article simplifies the problem and commits factual errors.
TPM is not HSM, not enclave, and it does not allow running arbitrary computation. TPM is a specification of a secure element, that provides some cryptographic primitives, secure storage, signing mechanism (endorsement key), and a few more. Since it is available since very early boot stage it is used for storing and signing integrity measurements.
HSM or TPM never release the signing key as authors writes. DICE does not release the initial seed used to derive the inital hash/key.
DICE addresses different market. It was designed by the same organization that designed TPM but addresses IoT devices. Microsoft extended the spec so that one gets chain of signed measurements instead of an aggregated hash as an attestation proof (at a high level).
DICE gets more popular in TEE designs because one does not have to rely on an external chip vulnerable to physical attacks. However, it is the same set of features needed for DICE and TPM to enable attestation. TPM offers additional features, like mono tonic counters, secure storage, sealing, etc, that can be used for other use cases.
Finally, TPM became a standard and has been implemented as part of complex processor’s firmware (Intel PTT), discrete TPM (what the author of the article is familiar with), software TPMs enabling attestation for VMs and recently used also for confidential computing VMs (check Intel TDX). Linux kernel supports runtime integrity measurements with IMA security subsystem that relies on TPM protocol for attestation.
Your nitpicks and misinterpretations are not my factual errors.
> TPM is not HSM
Most TPMs we care about are their own piece of silicon. The software and firmware ones aren't real HSMs, but come on, we all know those are shortcuts to the real thing.
> TPM is […] not enclave
Never mentioned "enclave" in my article.
> TPM […] does not allow running arbitrary computation.
Hey, I said as much, that's the whole point of my article.
> TPM is a specification […]
Oh please. Can't I use the same word to refer to the TCG specs and actual instantiations in hardware or software?
> HSM or TPM never release the signing key as authors writes.
I never wrote that.
> DICE does not release the initial seed used to derive the inital hash/key.
Which is why I never said it did.
> DICE addresses different market. […]
Yes, I'm aware. I also noticed how the TCG manages to promote DICE without noticing it makes their baby TPM 2.0 obsolete. I'm guessing this is motivated cognition. In any case, I think the TCG should start working on a DICE-capable TPM 3.0 right away, and spare us the now needless complexity of TPM 2.0.
> I also noticed how the TCG manages to promote DICE without noticing it makes their baby TPM 2.0 obsolete.
Alas, TCG seems to have recognized the mistake, so they have recently proposed for the DICE to rely on a separate entity (the DPE) to handle all secrets and cryptographic operations:
"Examples of environments that could be used for a DPE implementation are a secure coprocessor, discrete secure hardware, a Trusted Execution Environment (TEE), a type-1 hypervisor, operating system kernel, or another type of environment isolated with a
hardware-backed mode switch."
The DPE re-introduces a whole class of problems (i.e. authentication and secure communications) that the DICE was meant to simplify away in the first place.
From what I got, the OP was not claiming that a TPM is simply a HSM (despite the first sentence making it seem that way).
What they claimed was:
- You only need to provide a HSM, a general-purpose microcontroller and a specific, very simple trusted bootloader.
- Then clients can supply the rest of the TPM implementation themselves as untrusted code to the bootloader.
- The resulting system has the same security properties as a TPM implemented in firmware.
- It would lead to simpler implementations and a lot less complexity in general, as clients only have to implement the parts of the TPM spec they need an not the entire thing.
I'm not enough of a crypto guy to be able to judge whether OP is right - but I think you'd need some more substantial cryptographic arguments to disprove the claim.
(In particular, I wonder how easy it would be to cause a collision - i.e. pass a program to the bootloader that results in the same hash and CDI as the program that you want to attack and still lets you do something useful, such as leaking information about the CDI to the host)
