TEEM³: Core-Independent and Cooperating Trusted Execution Environments

Nils Asmussen, Sebastian Haas, Carsten Weinhold, Nicholas Gordon, Stephan Gerhold, Friedrich Pauls and 2 others

A Trusted Execution Environment lets you run sensitive code on a machine you do not fully trust, but today's TEEs are baked into a specific CPU and instruction set — so a system with a CPU plus accelerators ends up with several different, incompatible TEE designs, a bigger pile of trusted code, and no clean way to connect them; this paper (Barkhausen Institut — Nils Asmussen, Michael Roitzsch, and colleagues) presents TEEM3, which moves the security enforcement out of the core into a separate unit shared by every processing element, so one TEE mechanism serves any core and cooperating TEEs get secure channels for free — shrinking the trusted hardware by 1.8 times and trusted software by 3.42 times.

The argument in one glance

Problem

Trusted execution is built into each core, so a mixed system needs many of them

A Trusted Execution Environment (TEE) lets a user run sensitive code on a machine they do not fully control — a cloud server, say — while keeping that code and its data protected from everything else on the machine, including a possibly-malicious operating system or hypervisor. The catch is how TEEs are usually built: the enforcement lives inside the CPU core, woven into its memory management and pipeline, and tied to one specific instruction set architecture. Intel, ARM, and AMD each have their own, mutually incompatible TEE designs. That was tolerable when a workload ran on one CPU, but modern workloads increasingly span heterogeneous processing units — a CPU alongside GPUs and other accelerators — and increasingly those accelerators offer their own TEE support too. The result is a system carrying several different TEE implementations at once, each with its own trusted hardware and software. This inflates the trusted computing base (TCB) — the total set of components that must be correct for security to hold, where every added line is another place a bug could break everything — and it makes the diversity itself a problem: when a workload's pieces run in different kinds of TEEs, there is no uniform way to build a secure channel between them, so getting two TEEs on different processing units to cooperate safely is awkward and error-prone. The very heterogeneity that makes modern systems powerful makes their trusted execution a fragmented mess.
What people did

Give each processor its own TEE and bridge them case by case

The prevailing approach is to equip each kind of processing unit with its own TEE: the CPU uses its vendor's enclave technology, and an accelerator that supports confidential execution uses whatever mechanism its designers built in. When a workload needs to span them — data prepared in a CPU enclave and processed in an accelerator TEE, for instance — the two are stitched together with bespoke, implementation-specific glue to pass data between the different trust domains. Each TEE is designed and trusted on its own terms, and the connections between them are handled ad hoc.
Why it fell short

Many per-core TEEs mean a large, fragmented trusted base and clumsy secure channels

Building trusted execution into each core, once per architecture, has two compounding costs. First, the trusted computing base balloons: every distinct TEE implementation brings its own trusted hardware and its own trusted software, and because all of them must be correct, the attack surface grows with the number of designs on the system. A heterogeneous machine ends up trusting several independent, complex mechanisms rather than one. Second, the fragmentation makes cooperation hard. Because each TEE speaks its own dialect of isolation and attestation, connecting a TEE on the CPU to a TEE on an accelerator requires reconciling incompatible trust models and building secure communication channels by hand for each pairing. There is no shared substrate that says how any two protected components talk safely, so every combination is a new engineering and verification problem. And tying enforcement to a specific instruction set means the whole apparatus cannot simply be reused when a new kind of core is added — it must be reinvented. What was missing was a trusted execution architecture that did not live inside any particular core, so that one mechanism could serve every processing unit and give all of them a common, secure way to communicate.
This paper's idea

Move enforcement out of the core, and share one trusted substrate across all units

TEEM3 is a trusted execution architecture with discrete, out-of-core enforcement: instead of building the TEE into each CPU core, it enforces isolation from a separate unit that sits between every processing element and the rest of the system, so the same mechanism works regardless of what kind of core — CPU of any instruction set, or accelerator — it is protecting. It builds on M3, a hardware-and-OS architecture in which each processing element is attached to a small communication unit that mediates all its access to memory and to other elements, giving every element a uniform way to communicate no matter what is inside it. TEEM3 extends both the M3 hardware and its OS. On the OS side, it adds a root of trust (RoT) for remote attestation — the anchor that lets a user verify a TEE is running the expected code on genuine trusted hardware — and a unikernel-like library that lets a workload be built as a small, self-contained TEE. On the hardware side, it adds two lightweight isolation mechanisms that protect both the TEEs and the root of trust from every other component in the system. Crucially, because M3 already gives all processing elements uniform communication channels, TEEM3 simply protects those channels, so groups of TEEs on different, heterogeneous units can cooperate over secure connections that come from the shared substrate rather than being hand-built per pairing. The paper reports that this adds low performance overhead and modest hardware cost while shrinking the hardware TCB by 1.8 times and the software TCB by 3.42 times relative to prior approaches.

Why this problem is worth solving

Trusted execution is only as strong as its trusted computing base is small, so a design that multiplies TEEs is quietly undermining the security it provides.

The point of a TEE is to shrink what you have to trust: instead of trusting the entire software stack and the cloud operator, you trust only a small, well-scrutinized set of hardware and software — the trusted computing base. Security holds exactly as long as every component in that base is correct, because a single bug anywhere in it can compromise everything the TEE was protecting. This is why minimizing the TCB is a foundational principle of secure system design: fewer trusted components mean fewer places for a flaw to hide and a smaller target for attackers to study. Now consider what happens on a heterogeneous machine with a TEE built into the CPU, another into the GPU, and another into some accelerator: the TCB is no longer one small, carefully-audited thing but the union of several independent, complex mechanisms, each with its own hardware and software to trust. The whole is larger and harder to verify than any of its parts, and it grows every time a new kind of TEE is added. So consolidating heterogeneous trusted execution into a single shared mechanism is not just an engineering convenience — it directly serves the core security goal, shrinking the base of trust rather than accreting it. The paper’s reported reductions of the hardware and software TCB are precisely this benefit made concrete.

The deeper structural insight is that the tight coupling of security enforcement to the core is what causes both the fragmentation and the cooperation problem, and pulling them apart fixes both.

Conventional TEEs put the isolation machinery inside the CPU core, entangled with its instruction set and microarchitecture. That single choice has two consequences. It ties the TEE to one architecture, so every different core needs its own reinvented implementation, which is what multiplies the TCB. And it means there is no shared notion of how protected components communicate, because each core’s TEE defines its own, which is what makes cross-TEE channels ad hoc. TEEM3’s reframing is that enforcement does not have to live in the core at all. If a separate unit outside every core mediates that core’s access to memory and to other components, then isolation can be enforced there, uniformly, whatever the core is — a plain CPU, a different-ISA CPU, or an accelerator. This is exactly the structure M3 already provides for communication, so TEEM3 gets to define trusted execution once, at that out-of-core layer, and have it apply everywhere. The payoff is twofold and comes from the same decision: one mechanism instead of many (shrinking the TCB), and one uniform, protectable communication fabric that lets TEEs on different units talk securely without bespoke bridges (enabling cooperation). It is a general lesson that appears whenever a capability is welded into a component that varies: lifting the capability out to a common layer that all the varying components share can dissolve a whole class of compatibility and duplication problems at once.

What people did before, and where it broke

CPU-vendor TEEs (enclaves tied to one instruction set). Build isolation into the CPU core, specific to Intel, ARM, or AMD. Where it broke. Each is tied to one architecture and cannot serve other cores, so heterogeneous systems need several different designs.
Accelerator-specific TEEs. Add confidential-execution support inside each accelerator on its own terms. Where it broke. This adds yet another distinct TEE implementation, with its own trusted hardware and software, further inflating the trusted computing base.
Ad hoc bridges between TEEs. Stitch a CPU enclave and an accelerator TEE together with bespoke, per-pairing glue to move data across trust domains. Where it broke. With no shared trust model or channel, every combination is a new secure-channel engineering and verification problem, and it is error-prone.
In-core enforcement. Weave the isolation machinery into the core’s pipeline and memory management. Where it broke. Coupling enforcement to a specific instruction set means it must be reinvented for every new core type rather than reused.
The gap. No trusted execution architecture was core-independent — enforced outside any particular core so one mechanism could serve every processing unit and give them all a common, secure way to communicate.

How TEEM3 works

From per-core TEEs to one out-of-core mechanism serving every unit

↓ →
new
↓ →
new
↓ →
new
↓ →
new
↓ →
new

The idea

Protect a workload from the machine it runs on. At its core TEEM3 is a confidential-computing mechanism: it lets sensitive code run on hardware the user does not fully trust, shielded from the surrounding software. Creating a protected execution environment that keeps a workload and its data secret and intact even from a privileged, untrusted host is the same confidential-computing goal the work on a protected services framework for confidential virtual machines (VEIL) covered elsewhere on this site is built on, isolating the trusted workload from everything around it. TEEM3 pursues that goal for whole heterogeneous systems rather than a single CPU, and focuses on doing it with one shared mechanism.

Decouple protection from the thing being protected. TEEM3’s central move is to lift isolation out of the core and into a separate, shared layer, so the enforcement no longer depends on which core it guards. Separating the isolation mechanism from the component it isolates, so that protection is defined once and applied uniformly rather than baked into each part, is the same decoupling-isolation idea the work on flexible OS isolation (FlexOS) covered elsewhere on this site is built on, making the isolation boundary a configurable, independent concern. TEEM3 draws that boundary outside the core, which is exactly what makes its trusted execution core-independent.

Keep the trusted base as small as possible. TEEM3 deliberately minimizes what must be trusted — a small root of trust plus unikernel-sized TEEs — because every trusted component is a liability. Shrinking the root of trust and the surrounding trusted code to the smallest thing that still anchors security is the same minimize-the-trusted-base discipline the work on minimizing the root of trust for fast SEV microVM startup (SEVeriFast) covered elsewhere on this site pursues, cutting the trusted base down rather than letting it accrete. TEEM3 applies this across a heterogeneous system, and reports shrinking both the hardware and software trusted computing base substantially as a result.

Following a cooperating workload through TEEM3

From an untrusted machine to two TEEs on different units cooperating securely

An illustration, at the level the paper's abstract describes, of how TEEM3 sets up and connects TEEs. The full paper was not available for this explainer, so internal mechanism details are omitted.

Step 1 of 5

A user wants to run sensitive work on an untrusted host

The workload spans a CPU and an accelerator on a machine the user does not control. The user needs each piece to run protected from the host software, and the pieces to exchange data securely with each other.

Conventionally this would mean two different, incompatible TEEs.

Why it works

Out-of-core enforcement serves any core. Building the TEE into the core ties it to one instruction set → but enforcing isolation from a separate unit outside the core → so one mechanism protects CPUs of any architecture and accelerators alike.
One mechanism shrinks the trusted base. Several per-core TEEs each add trusted hardware and software → but consolidating them into a single shared design → so the total trusted computing base falls rather than accretes.
A shared substrate makes cross-TEE channels uniform. Bridging incompatible TEEs needs bespoke glue per pairing → but protecting M3’s already-uniform channels → so any two TEEs cooperate securely over the common fabric.
Unikernel TEEs keep each workload’s trusted software small. A full OS inside every TEE bloats what must be trusted → but a unikernel library including only needed functionality → so each TEE carries a minimal software base.
A single root of trust anchors the whole system. Duplicating attestation per core multiplies trusted components → but one shared root of trust for remote attestation → so the anchor of trust is not repeated for every unit.

What it costs (trade-offs and scope)

It requires the M3 architecture, not commodity CPUs. TEEM3’s core-independence comes from M3’s out-of-core communication units, so it is a hardware-and-OS co-design for that platform rather than a drop-in for existing Intel, ARM, or AMD systems.
Enforcement adds hardware and some overhead. The two isolation mechanisms and the protection of channels cost extra hardware and some performance; the paper reports these as modest and low, respectively, but they are not zero.
Trust now rests on the shared substrate. Consolidating into one mechanism means the out-of-core enforcement and shared root of trust must themselves be correct — the design shrinks the TCB, but the remaining base is critical and must be strongly assured.
The comparison is against particular alternatives. The 1.8-times hardware and 3.42-times software TCB reductions are relative to specific prior approaches in the paper’s setting; the advantage depends on what is being compared and how the systems are configured.
This explainer is built from the abstract only. The exact isolation mechanisms, the root-of-trust and attestation design, the channel protection, the evaluation platform, and the detailed TCB accounting are in the full paper, which was not available here; only the abstract’s stated design and headline numbers are reported.

The comparison

Providing trusted execution on a heterogeneous system

Property	Per-core CPU and accelerator TEEs	Ad hoc bridged TEEs	TEEM3
Where enforcement lives
Number of TEE designs to trust
Cross-TEE secure channels
Works across core types
Reported trusted computing base

A comparison of ways to provide trusted execution on a heterogeneous system. Per-core TEEs build isolation into each CPU and accelerator, tied to their instruction sets, so a mixed system trusts several different designs and has no uniform way to connect them; bridging them adds bespoke, error-prone glue. TEEM3 enforces isolation from outside the core on the M3 platform, so one mechanism serves any processing unit, a shared root of trust and unikernel TEEs keep the trusted base small, and TEEs on different units cooperate over protected shared channels — reducing the hardware trusted computing base by 1.8 times and the software by 3.42 times at low overhead. Exact figures should be read from the paper.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based only on the paper’s abstract and TLDR (obtained via Semantic Scholar); the full text was not available — the paper is behind the ACM Digital Library with no open preprint reachable at the time of writing, so this page is marked a draft. What is reported here is what the abstract states: existing TEEs mostly target CPUs and are tied to one instruction set, and accelerator TEEs add further different implementations, inflating complexity and the trusted computing base and complicating secure channels between TEEs on heterogeneous units. TEEM3 (styled TEEM cubed) is a trusted execution architecture with discrete, out-of-core enforcement that is core-independent, built on M3 by extending both the hardware platform and the operating system. On the OS side it adds a root of trust for remote attestation and a unikernel-like library for TEEs; on the hardware side it adds two lightweight isolation mechanisms protecting the TEEs and the root of trust from other components; and it protects M3’s uniform communication channels to support communicating groups of TEEs. The abstract reports low performance overhead, modest additional hardware cost, and reductions of the hardware trusted computing base by 1.8 times and the software trusted computing base by 3.42 times. Everything beyond these claims — the exact isolation mechanisms, the root-of-trust and attestation design, the channel protection, the evaluation platform, and the detailed TCB accounting — is not contained in the abstract and should be read in the full paper. Background on TEEs, trusted computing base, remote attestation, roots of trust, unikernels, and the M3 architecture is standard context, and the step-by-step walkthrough is an illustration at the abstract’s level, not a verbatim trace of the paper’s mechanism.

Background

Why confidential computing keeps fighting to shrink and unify what must be trusted

It helps to see TEEM3 within the broader push to run sensitive workloads on machines their owners do not control. Cloud and edge deployment mean users routinely hand their code and data to hardware operated by someone else, and trusted execution environments are the answer: hardware-enforced islands of protection that a small trusted base defends against everything around them. Two pressures shape this field. One is minimizing the trusted computing base, because security ultimately rests on that base being correct, so every line of trusted code or piece of trusted hardware is a liability to be pared away. The other is heterogeneity: workloads, especially machine-learning ones, spread across CPUs, GPUs, and specialized accelerators, and confidential computing has to follow them onto every one of those units and let them cooperate without leaking. The recurring difficulty is that TEEs grew up per-vendor and per-architecture, so extending confidentiality across a mixed system means reconciling incompatible designs and multiplying what must be trusted. This drive to provide hardware-rooted confidentiality across diverse processing units without exploding the trusted base is the same terrain the work on unifying heterogeneous TEE granularity for efficient secure computing (TensorTEE) covered elsewhere on this site occupies, bringing one coherent trust model to a mix of hardware. TEEM3’s distinctive answer is to stop building trusted execution into the cores at all, and instead enforce it from a shared, out-of-core substrate that every unit already uses to communicate.

If you remember only three things

1. A Trusted Execution Environment lets sensitive code run on a machine the user does not fully trust, protected from the rest of the software including a malicious OS or hypervisor. But conventional TEEs build the enforcement into the CPU core, tied to one instruction set (Intel, ARM, and AMD each differ), and accelerators that support TEEs add their own separate designs. On a heterogeneous system with a CPU and accelerators, this means carrying several different TEE implementations at once — inflating the trusted computing base (the set of components that must be correct for security to hold, where every addition is another place a bug could break everything) — and, because the designs are incompatible, leaving no uniform way to build secure channels between TEEs on different units, so cooperation is bespoke and error-prone.
2. TEEM3 is a trusted execution architecture with discrete, out-of-core enforcement: rather than building the TEE into each core, it enforces isolation from a separate unit that sits between every processing element and the rest of the system, so the same mechanism protects any core — a CPU of any instruction set, or an accelerator. It builds on M3, whose per-element communication units already give the system a uniform, core-independent communication structure. On the OS side, TEEM3 adds a shared root of trust for remote attestation and a unikernel-like library so each workload is a small, self-contained TEE; on the hardware side, two lightweight isolation mechanisms protect the TEEs and the root of trust from everything else. And because M3's communication channels are already uniform, TEEM3 protects them so groups of TEEs on different units cooperate securely over the shared fabric instead of hand-built bridges.
3. The core insight is that coupling security enforcement to the core is what caused both the fragmentation and the cooperation problem, and moving enforcement out of the core fixes both at once: one mechanism instead of many (shrinking the trusted base) and one protected communication fabric (enabling secure cross-TEE cooperation). The paper reports low performance overhead, modest additional hardware cost, and reductions of the hardware trusted computing base by 1.8 times and the software trusted computing base by 3.42 times. The trade-offs: TEEM3 requires the M3 platform rather than commodity CPUs, its enforcement adds some hardware and overhead, and the shared substrate it consolidates trust into must itself be strongly assured. This explainer is drawn only from the paper's abstract; the detailed mechanisms and evaluation should be read in the full paper.

Check yourself

Check your understanding

1. Why does trusted execution become fragmented and costly on a heterogeneous system?
2. Why is minimizing the trusted computing base (TCB) so important, and how does per-core TEE fragmentation hurt it?
3. What is TEEM3's central design move?
4. What else does TEEM3 add, and what did it achieve?

Sources

The paper is “TEEM3: Core-Independent and Cooperating Trusted Execution Environments” (styled TEEM cubed) by Nils Asmussen, Sebastian Haas, Carsten Weinhold, Nicholas Gordon, Stephan Gerhold, Friedrich Pauls, Nilanjana Das, and Michael Roitzsch (Barkhausen Institut), published at ASPLOS 2026, DOI 10.1145/3779212.3790232.

This explainer is written only from the paper’s abstract and TLDR, obtained via the Semantic Scholar API; the full text was not available, because the paper is behind the ACM Digital Library and no open preprint was reachable at the time of writing. Accordingly this page is marked a draft. The abstract describes TEEM3 as a trusted execution architecture with discrete, out-of-core enforcement that is core-independent and better-suited to heterogeneous systems than existing approaches, built on M3 by extending both the hardware platform and the operating system. On the OS side it adds a root of trust for remote attestation and a unikernel-like library for TEEs; on the hardware side it adds two lightweight isolation mechanisms to protect the TEEs and the root of trust from other components; and it inherits and protects M3’s uniform communication channels to support communicating groups of TEEs. The abstract reports low performance overhead, modest additional hardware cost, and reductions of the hardware trusted computing base by 1.8 times and the software trusted computing base by 3.42 times. Background on trusted execution environments, the trusted computing base, remote attestation, roots of trust, unikernels, and the M3 architecture is standard, widely-known context. All quantitative claims are the paper’s own; the internal mechanisms and full evaluation should be confirmed in the paper.

TEEM&#179;: Core-Independent and Cooperating Trusted Execution Environments