Make the Control Plane Part of the Boundary

The Silicon Heist study answers the opening question with a precise warning: a cloud FPGA can have a strong submission pipeline and still expose a dangerous isolation gap if a tenant design can reach low-level configuration or debug controls after deployment. The final focus here is what that means for the AWS F1/F2 case and for the design of programmable cloud hardware more generally. The reader should leave able to reconstruct the causal chain, identify where a provider can break it, and apply the same control-plane test without claiming that every accelerator has the same vulnerability.

The failure was in the transition

The most useful way to understand the case is as a change in who may cause the device to move from one state to another. At the start, a customer has ordinary cloud access. They create a hardware design, submit it through the provider’s workflow, and wait for checks, image generation, and programming. The provider shell owns the host-facing infrastructure and the path that turns an approved design into a running region. The customer receives useful computation, but not authority over the configuration machinery that makes the service possible.

The first break occurs when the running design can reach ICAP. The study reports that a customer could instantiate an ICAPE3 component in a secondary region even though vendor guidance placed such configuration resources in the static part of the design. The evaluated AWS verification path did not prohibit that instantiation. Once the design was active, the ICAP connection could send configuration operations to the engine from inside the device. The customer’s role changed from supplying an artifact to participating in later hardware state transitions.

The second break is not independent. ICAP access made it possible to activate internal MASTER_JTAG, a primitive that ordinary verification blocked when instantiated directly. JTAG exposed eFuse state and other low-level functions normally associated with testing and debugging. The researchers used it to read security-relevant registers and device identity on cloud hardware. The path did not begin as a remote JTAG port offered by the cloud API. It was assembled by crossing one boundary that made a second boundary reachable.

The third step is persistence. E-fuses on the evaluated AMD devices store key material and security-policy settings in non-volatile, one-time-programmable state. A local validation showed how attacker-controlled keys and a policy requiring encrypted and authenticated bitstreams could make future provider-generated images unacceptable, especially if further eFuse changes were disabled. The study calls the resulting possibility ransomware because the provider’s hardware capacity and recovery authority could be held hostage. But the authors did not perform that irreversible write on AWS; they tested the cloud path non-destructively and validated the destructive mechanism locally.

These transitions explain why the central failure is not simply “a missing check.” A missing check was one contributing condition. The deeper problem was that the system treated a hardware capability as if it were contained by the artifact that first declared it. The provider checked a submitted design, but the effective device had a continuing configuration lifecycle. When an untrusted tenant design could initiate a later transition, the object being verified and the actor controlling the next state were no longer the same.

flowchart TD A["Tenant design"] --> B["Approved image"] B --> C["Running FPGA fabric"] C --> D["ICAP control path"] D --> E["Internal JTAG"] E --> F["eFuse security state"] F --> G["Persistent lockout risk"] D -. "Break chain: ban or mediate ICAP" .-> M["ICAP control" ] C -. "Break chain: independent monitoring" .-> R["Runtime detection or halt"] E -. "Limit persistence: preemptive eFuse policy" .-> P["Protected recovery state"] B -. "Limit reach: quotas and health checks" .-> Q["Constrained fleet exposure"] G --> T["Review tenant-caused hardware transitions"] M --> X["Functionality trade-off"] R --> Y["Coverage and trust trade-off"] P --> Z["Irreversibility trade-off"] Q --> W["Scale limitation, not primitive removal"]

The chain is powerful precisely because each transition preserves some of the previous one. ICAP does not have to control the whole device to be dangerous. It only needs access to a meaningful region and the ability to submit configuration commands there. JTAG does not have to expose every debug function to matter. It only needs to reach the eFuse state that determines how future configuration is accepted. The final lockout does not have to destroy every FPGA resource to impose cost. It only needs to make ordinary recovery depend on keys the provider does not hold.