Salus: A Practical Trusted Execution Environment for CPU-FPGA Heterogeneous Cloud Platforms

Clouds now rent FPGAs next to CPUs to accelerate work, but if you run sensitive data on a rented FPGA you have to trust the cloud operator not to peek or tamper, and earlier attempts to build a trusted zone on the FPGA needed hardware changes you simply cannot make on an off-the-shelf cloud FPGA; this work from Alibaba and Tsinghua builds Salus, which instead anchors trust in the host CPU's existing secure enclave and, from there, protects and vouches for the exact design loaded onto the FPGA — reusing the cloud's own bitstream tools in a new way plus a small security block added to the user's design — so a practical trusted execution environment for CPU-FPGA clouds needs only minor changes.

The argument in one glance

Problem

Sensitive data on a rented FPGA has to trust the cloud

Clouds pair CPUs with FPGAs to accelerate work, but a tenant running sensitive data on a rented FPGA must trust the operator and the host software not to read or tamper with the data and the hardware design loaded on it. A trusted execution environment is needed on the FPGA side, not just the CPU side.
What people did

Build a standalone FPGA TEE by changing the hardware

Add protection and attestation to the FPGA itself by modifying its trusted shell or hardware, as prior standalone FPGA trusted-execution designs do.
Why it fell short

You cannot change an off-the-shelf cloud FPGA

On commercial-off-the-shelf cloud FPGA services the provider controls the shell and the bitstream-loading path, so tenants cannot make those hardware changes. And standalone designs never integrate with the host CPU enclave, so they do not fit a real rented CPU-FPGA platform.
This paper's idea

Anchor trust in the host enclave and attest the bitstream (Salus)

Salus, according to its abstract, runs an enclave on the host with a TEE-enabled CPU and uses it to protect and attest the bitstream loaded on the FPGA. By repurposing off-the-shelf FPGA bitstream utilities in a novel way and adding a small security-enhanced FPGA IP to the user design, it builds a practical CPU-FPGA trusted execution environment with only minor effort.

Why this problem is worth solving

Renting an accelerator in the cloud is now routine, but it quietly asks the tenant to trust a great deal.

Cloud providers increasingly offer FPGAs — field-programmable gate arrays, chips whose logic can be reconfigured by loading a hardware design — alongside CPUs, so that a tenant can offload a compute-intensive task (encryption, genomics, machine-learning inference, database operators) onto custom hardware that runs it far faster than a general processor. The tenant programs the FPGA by loading a bitstream, the compiled hardware design, and streams data to and from it. The problem is trust. In the cloud the tenant does not own the machine; the operator’s privileged software sits underneath everything, and a malicious insider or a compromised hypervisor could in principle observe or alter the sensitive data being processed, or even swap the hardware design. On the CPU this is exactly what a trusted execution environment addresses: a hardware-enforced enclave isolates a piece of code and its data so that even the operating system, hypervisor, and cloud operator cannot see inside, and it supports remote attestation, letting the tenant cryptographically verify what code is running before entrusting it with secrets. The natural desire is the same guarantee for the FPGA, so that the accelerated part of a computation is as protected as the part on the CPU.

The obstacle is that the FPGA in a real cloud is not yours to modify, which is where prior designs fall short.

Building a trusted execution environment for an FPGA sounds like it should mirror the CPU case: add hardware that isolates the tenant’s logic and can attest it. But a cloud FPGA is wrapped in a provider-controlled shell — the fixed infrastructure logic that manages the board, the connection to the host, and crucially the path that loads and verifies bitstreams. On commercial-off-the-shelf cloud FPGA services the tenant only gets to fill in a region of user logic; they cannot alter the shell, the bitstream-loading mechanism, or the board’s root of trust. Prior FPGA trusted-execution work largely assumes exactly the freedom the cloud denies: it modifies the shell or the hardware to insert protection and attestation, which is impossible to deploy on a rented off-the-shelf FPGA. Moreover, that earlier work generally treated the FPGA as a standalone trusted device, designing its security in isolation rather than tying it to the host CPU’s enclave — so even setting deployability aside, it does not naturally compose into an end-to-end guarantee across a CPU-FPGA platform, where the interesting workloads span both. The practical question the paper takes on is how to get a trustworthy accelerator using only what an off-the-shelf cloud service already exposes.

What people did before, and where it broke

Protect only the CPU side with a TEE. Run the sensitive code in a CPU enclave and offload the rest to the FPGA unprotected. Where it broke. The accelerated portion, and the data streamed to the FPGA, sits outside the enclave’s protection, so sensitive computation on the accelerator is exposed.
Build a standalone FPGA TEE by modifying the shell. Add isolation and attestation logic into the FPGA’s trusted shell or hardware. Where it broke. On off-the-shelf cloud FPGAs the provider owns the shell and the bitstream-loading path; a tenant cannot change them, so these designs cannot be deployed.
Assume a custom or on-premises FPGA platform. Design the security assuming full control of the board and its root of trust. Where it broke. That does not match commodity cloud FPGA services, where tenants only receive a region of user logic and standard utilities, so the approach is impractical for the setting that matters.
Treat the FPGA TEE in isolation from the host. Secure the FPGA as a standalone device without integrating the host CPU enclave. Where it broke. Real workloads span CPU and FPGA, so a guarantee that does not connect to the host enclave leaves the end-to-end path untrusted.
The gap. No design delivered a trusted execution environment for CPU-FPGA platforms that works within off-the-shelf cloud constraints and ties the FPGA to the host CPU enclave. Providing that, by anchoring trust in the host enclave and repurposing existing bitstream utilities plus a small security IP, is what Salus does.

How Salus works

From an unmodifiable cloud FPGA to an attested, protected accelerator

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

The idea

Put the root of trust where you already have one: the host enclave. Salus’s key decision, per its abstract, is not to try to manufacture a new trust anchor inside an FPGA the tenant cannot modify, but to start from the trust anchor that already exists and is deployable — a hardware enclave on a TEE-enabled host CPU, which is protected from the cloud operator and privileged software and can be remotely attested. From that trusted base, Salus reaches outward to protect and vouch for the FPGA side. Building a protected workload by extending an established hardware trust base to cover more of the system, rather than inventing isolation from scratch, is the same move the confidential-services work covered elsewhere on this site makes, taking a hardware-backed protected domain and constructing on top of it a framework that shields a broader set of services from an untrusted host.

Vouch for the exact design loaded on the accelerator. A protected CPU enclave is not enough if the FPGA it offloads to has been quietly swapped or tampered with, so Salus protects and attests the bitstream — the specific hardware design running on the FPGA — so the tenant can be sure the accelerator is the one they intended and has not been altered. This is the FPGA analogue of attesting what code runs in an enclave, extended across the boundary to the reconfigurable hardware. Cryptographically establishing that data or logic outside the trusted core has not been tampered with before relying on it is the same discipline the secure-memory integrity work covered elsewhere on this site is built on, attaching verification to content that leaves the protected boundary so that any tampering by an untrusted party is detected rather than silently accepted.

Be practical: reuse what the cloud already gives you. The design’s most pragmatic move is to demand almost nothing new from the platform. Instead of requiring modified hardware or a custom shell, Salus repurposes the commercial-off-the-shelf FPGA bitstream utilities the cloud already provides — using them in a novel way — and adds only a small security-enhanced IP block inside the tenant’s own logic, so the whole scheme deploys with minor effort on real cloud FPGA services. Making a capability work within the constraints and toolchain of existing commodity infrastructure, rather than assuming hardware or platform changes a user cannot make, is the same design the reconfigurable-acceleration compatibility work covered elsewhere on this site follows, fitting FPGA acceleration into the systems and flows that are already deployed so it can actually be adopted instead of remaining a design that only runs on bespoke hardware.

Following a protected offload through Salus

Running a confidential task across a host enclave and a cloud FPGA

A conceptual trace based on the paper's abstract and standard TEE and cloud-FPGA background; specific protocol and implementation details were not available.

Step 1 of 5

The tenant starts a host enclave

On a TEE-enabled cloud CPU, the tenant launches an enclave that isolates the sensitive part of the computation from the operator and the host operating system, and can be remotely attested by the tenant.

This is the deployable trust anchor Salus builds on.

Why it works

The host enclave is a trust anchor you can actually deploy. Because a TEE-enabled CPU already provides an enclave isolated from the operator → Salus can root its guarantees there instead of in unmodifiable FPGA hardware → so the design works on off-the-shelf cloud services.
Attesting the bitstream closes the swap gap. Because a protected CPU enclave still offloads to an FPGA that could be tampered with → protecting and attesting which bitstream is loaded verifies the accelerator is genuine → so trust extends across the CPU-FPGA boundary rather than stopping at the CPU.
Reusing bitstream utilities avoids needing new hardware. Because the cloud already provides tools to load and manage bitstreams → repurposing them in a novel way delivers protection without shell changes → so the scheme fits commodity FPGA services the tenant cannot modify.
A small security IP fits inside the tenant’s own logic. Because the tenant does control their region of user logic → adding a minimal security-enhanced IP there gives the FPGA a trusted component without touching the provider shell → so the FPGA side can cooperate with the host enclave.
Anchoring in the host ties the two sides together. Because standalone FPGA TEEs never integrate with the host enclave → building outward from that enclave produces one end-to-end guarantee → so a workload spanning CPU and FPGA is protected as a whole.

What it costs (trade-offs and scope)

This explainer is based on the abstract, not the full paper. The full text was not openly available at the time of writing, so the specific protocol, the cryptographic mechanisms, exactly how the bitstream utilities are repurposed, the internals of the security-enhanced IP, the threat model boundaries, and the performance results are not reflected here beyond what the abstract states.
Trust still rests on the host CPU TEE. Salus anchors its guarantees in the host enclave, so the scheme inherits that TEE’s trust assumptions and any weaknesses it has, such as side channels the underlying enclave technology is subject to. The abstract does not detail these limits.
A small trusted component is added to the FPGA. The security-enhanced IP occupies part of the tenant’s user logic and must itself be trusted and correct. Its resource cost and the assumptions it makes are part of the full design rather than the abstract.
It targets commercial-off-the-shelf cloud FPGA services. The design’s whole point is to fit within what commodity cloud FPGAs expose, so it is scoped to that setting; platforms with very different shells, loading paths, or trust models might require different adaptations.
No performance numbers appear in the abstract. The abstract emphasizes practicality and minor effort but does not quantify overhead, so any assessment of runtime cost, attestation latency, or resource usage must await the full paper. None are invented here.
Repurposing utilities may depend on provider specifics. Because the approach reuses off-the-shelf bitstream utilities, its exact realization may depend on the particular cloud FPGA service and the tools it exposes, which the full paper would specify.

The evaluation

Approaches to protecting a CPU-FPGA cloud workload

Property	CPU enclave only	Standalone FPGA TEE
What is protected
Root of trust	Host CPU enclave
Runs on off-the-shelf cloud FPGAs	FPGA left unprotected
Attests the FPGA bitstream	No	Sometimes, via custom hardware
Deployment effort	Low, but incomplete

Approaches to protecting a CPU-FPGA cloud workload, as framed by the Salus abstract (the full paper was not openly available, so this reflects the abstract's claims and standard background rather than the paper's detailed evaluation). Protecting only the CPU side with an enclave leaves the accelerated computation and the data streamed to the FPGA exposed. Standalone FPGA trusted-execution designs protect the FPGA but assume the tenant can modify its shell or hardware to insert isolation and attestation, which is impossible on commercial-off-the-shelf cloud FPGA services where the provider controls the shell and the bitstream-loading path, and they do not integrate with the host CPU enclave. Salus instead anchors the root of trust in an enclave running on a TEE-enabled host CPU, and from there protects and attests the bitstream loaded on the FPGA. It does so by repurposing the cloud's own off-the-shelf FPGA bitstream utilities in a novel way and adding a small security-enhanced FPGA IP inside the tenant's user logic, giving an end-to-end trusted execution environment across CPU and FPGA that deploys on real cloud services with only minor effort. The abstract does not report quantitative overhead, so the comparison is qualitative.Underlined values explain themselves when clicked.

Where this stops working

What to keep in mind

This explainer is based on the paper’s abstract, because the full text was not openly accessible when it was written, so read it as a faithful account of the abstract’s claims plus standard, well-established background on trusted execution environments, remote attestation, FPGAs, bitstreams, and cloud FPGA services — not as a report of the paper’s detailed protocol or evaluation. With that caveat, the contribution is clearly framed. Cloud providers rent FPGAs next to CPUs so tenants can accelerate compute-intensive work, but a tenant processing sensitive data on a rented accelerator must trust the operator and the host software not to peek at or tamper with the data and the hardware design. On the CPU this is solved by a hardware enclave that isolates code and data and can be remotely attested, and the natural wish is the same guarantee for the FPGA. The difficulty is that a cloud FPGA is wrapped in a provider-controlled shell that the tenant cannot modify, while prior FPGA trusted-execution designs assume exactly that freedom and treat the FPGA as a standalone device unconnected to the host enclave. Salus’s insight is to root trust in the deployable anchor that already exists — an enclave on a TEE-enabled host CPU — and from there protect and attest the bitstream loaded on the FPGA, using the cloud’s own off-the-shelf bitstream utilities in a novel way plus a small security-enhanced IP added to the tenant’s user logic, so the scheme runs on commodity services with only minor effort. What is not available here is how the protection and attestation protocol actually works, what cryptography and trust assumptions it relies on, how the utilities are repurposed, what the security IP costs in resources, where the threat-model boundaries lie (including side channels inherited from the host TEE), and what runtime overhead it imposes — the abstract reports no numbers. The durable idea worth taking even from the abstract is that a trusted execution environment for a heterogeneous platform need not reinvent isolation on every device; it can extend an existing, deployable trust anchor outward and lean on the infrastructure already in place, trading a clean-slate design for something a tenant can actually run in a real cloud.

Background

Why heterogeneous clouds keep pushing trust across new boundaries

It helps to see Salus within a broader shift toward heterogeneous computing, where a workload no longer runs on one processor but spans CPUs, FPGAs, GPUs, and other accelerators, often rented in a cloud the tenant does not control. Every time computation moves onto a new kind of device, the question of how to trust that device — and how to protect data as it crosses to it — has to be answered again, because the isolation and attestation mechanisms built for CPUs do not automatically extend to reconfigurable or specialized hardware. The open CPU-FPGA platform work covered elsewhere on this site reflects the same heterogeneous trend from the systems-research side, providing a tightly coupled CPU-FPGA machine precisely so that the hard questions of how the two should cooperate can be studied, of which secure cooperation is one. The common thread is that as accelerators proliferate, security can no longer stop at the CPU boundary; the trust guarantees users rely on must be carried across to whatever hardware actually touches their data, ideally without demanding changes to infrastructure the user cannot modify. Salus’s approach — anchor in the host enclave, attest the accelerator, and reuse the commodity toolchain — is one pragmatic template for doing that, and as confidential computing expands to more kinds of accelerators, the tension it navigates between strong guarantees and real-world deployability is likely to keep recurring.

If you remember only three things

1. Cloud providers pair CPUs with FPGAs — reconfigurable chips programmed by loading a hardware design called a bitstream — so tenants can accelerate compute-intensive tasks, but running sensitive data on a rented accelerator means trusting the operator and host software not to read or tamper with the data and the design. On the CPU this is handled by a trusted execution environment (TEE): a hardware enclave that isolates code and data even from a privileged, malicious host and can be remotely attested to prove what is running. Extending that guarantee to the FPGA is hard because a cloud FPGA is wrapped in a provider-controlled shell — the fixed logic managing the board, host connection, and bitstream loading — that the tenant cannot modify. Prior FPGA trusted-execution designs assume exactly the freedom the cloud denies (modifying the shell or hardware) and treat the FPGA as a standalone device unconnected to the host enclave, so they cannot be deployed on commercial-off-the-shelf cloud FPGA services.
2. Salus, according to its abstract, takes a practical approach: it anchors the root of trust in an enclave running on a TEE-enabled host CPU — a protected, attestable base that already exists and is deployable — and from there protects and attests the bitstream loaded on the FPGA, so the tenant can be sure the accelerator is the genuine, untampered design. Rather than demand new hardware, Salus repurposes the cloud's own off-the-shelf FPGA bitstream utilities in a novel way and adds only a small security-enhanced FPGA IP block inside the tenant's own user logic, giving the FPGA a minimal trusted component that cooperates with the host enclave. The result is an end-to-end trusted execution environment spanning CPU and FPGA that runs on commodity cloud services with only minor effort, instead of requiring changes the tenant cannot make.
3. Important caveat: this explainer is based on the abstract because the full paper was not openly available, so the specific protection-and-attestation protocol, the cryptography and trust assumptions, exactly how the bitstream utilities are repurposed, the internals and cost of the security IP, the threat-model boundaries (including side channels inherited from the host TEE), and the performance overhead are not reflected here — the abstract reports no numbers, and none are invented. The durable idea, clear even from the abstract, is that a trusted execution environment for a heterogeneous platform need not reinvent isolation on every device: it can extend an existing, deployable trust anchor (the host enclave) outward to cover the accelerator and lean on the commodity infrastructure already in place, trading a clean-slate design for one a tenant can actually run in a real cloud. This should be confirmed against the full paper when it becomes available.

Check yourself

Check your understanding

1. Why does running sensitive data on a rented cloud FPGA create a trust problem?
2. Why could prior FPGA trusted-execution designs not be deployed on commercial-off-the-shelf cloud FPGAs?
3. What is Salus's core approach, according to its abstract?
4. What should you keep in mind about the evidence behind this explainer?

Sources

The paper is “Salus: A Practical Trusted Execution Environment for CPU-FPGA Heterogeneous Cloud Platforms” by Yu Zou, Yiran Li, Sheng Wang, Le Su, Zhen Gu, Yanheng Lu, Yijin Guan, Dimin Niu, Mingyu Gao, Yuan Xie, and Feifei Li, published at ASPLOS 2024, DOI 10.1145/3622781.3674169. The authors are affiliated with Alibaba (DAMO Academy) and Tsinghua University.

This explainer is based on the paper’s abstract. The full text was not openly accessible at the time of writing — the ACM Digital Library copy was gated behind a bot check, there was no arXiv or author preprint available (the co-authors’ publication pages link only to the ACM DOI), and the Semantic Scholar, OpenAlex, and Unpaywall records pointed only to the gated version — so this page reflects the abstract’s stated claims (that CPU-FPGA heterogeneous clouds need an FPGA trusted execution environment; that deploying existing solutions on commercial-off-the-shelf cloud FPGA services is challenging and prior work focused on standalone FPGA TEEs; and that Salus leverages an enclave on a TEE-enabled host CPU to protect and attest the bitstream loaded on the FPGA, by repurposing off-the-shelf FPGA bitstream utilities in a novel way and adopting a proposed security-enhanced FPGA IP, giving a practical design with minor effort required) together with standard, well-established background on trusted execution environments, remote attestation, FPGAs, bitstreams, provider shells, and cloud FPGA services, provided to make the abstract’s contribution understandable. The specific protocol, cryptographic mechanisms, security-IP internals, threat model, and performance results are not reflected here beyond what the abstract states; the flow and step-through sections are conceptual readings of the abstract plus standard background rather than details drawn from the full paper, and the abstract reports no quantitative results, so none are stated here. This page is marked as a draft for that reason and should be confirmed against the full paper when it becomes available.