When the Tenant Can Reach the Hardware Control Plane
The subject of this series is Silicon Heist: (Ransom) Attacks for Cloud FPGAs via Privilege Escalation, a USENIX Security 2026 study of AMD-based FPGA instances offered through Amazon Web Services. Its immediate focus is a deceptively simple question: what happens when a customer’s hardware design can reach the device’s own configuration and debugging controls after the cloud provider has approved the design? Following that question gives readers a practical way to understand the difference between software isolation and hardware isolation, and to judge which parts of the paper’s ransomware scenario were demonstrated, locally validated, or projected as risk.
The subject is provider-owned hardware
A cloud FPGA is not a virtual machine with a different instruction set. It is a physical, reconfigurable circuit that a customer can rent and program for a particular workload. The fabric contains configurable logic, memory, specialized processing blocks, and programmable connections among them. That flexibility is useful for workloads such as machine learning, signal processing, and video transformation, but it also changes what “running customer code” means. A customer is not merely asking a processor to execute instructions inside a protected software process. They are asking provider-owned hardware to assume a new physical arrangement of logic and connections.
The Silicon Heist study examines this arrangement on Amazon’s EC2 F1 and F2 FPGA instances, which use AMD Virtex UltraScale+ devices. Amazon does not hand a customer the entire chip. Instead, the provider supplies a shell: hardware that handles the connection to the host system, receives the customer image, and manages the path into the reconfigurable area. The customer supplies logic that is placed alongside that shell in an area reserved for tenant designs. The shell and the customer region are meant to cooperate, but they do not have equal authority. The provider must retain control of the interfaces that make the service usable and safe.
That division creates a distinctive security obligation. A malicious software process can be stopped by a hypervisor or operating-system boundary if it tries to access memory that does not belong to it. A malicious hardware design may instead create power demand, observe signals, alter routing, or invoke a device feature that the provider did not intend to expose. Earlier cloud-FPGA research had already considered denial-of-service, hardware damage, side channels, and other forms of abuse. The study’s contribution is to show how a tenant can move closer to the device’s own control machinery, rather than merely misusing the computational resources assigned to them.
The shell is therefore more than a wrapper around customer logic. It is the mechanism that makes a physical device look like a service with a controlled API. It connects the FPGA to the host, participates in loading customer logic, and occupies resources that the customer is not supposed to instantiate or modify. A useful isolation model must account for both sides of that arrangement: what the tenant is allowed to configure and what the provider must keep stable while the tenant is running. If the second part is enforced only by assumptions about the submitted design, the service may expose a capability boundary without realizing it.
This is also why the case cannot be reduced to the familiar question of whether two customers share memory. The relevant state includes the physical configuration of logic and routing, the interfaces that write that configuration, and security settings that survive a reset. The customer’s legitimate workload may be perfectly ordinary; the concern is that the same programmable substrate used to accelerate it may contain a route to controls that govern the substrate itself. The study examines that route on two generations of Amazon FPGA instances, making the provider shell and the tenant boundary part of the subject rather than background scenery.
Isolation is a contract, not a wall
The normal cloud-FPGA workflow looks reassuring because it contains several checkpoints. A customer creates a design with the vendor’s tools and the cloud provider’s development kit. The resulting design checkpoint is sent to a provider-controlled service. That service checks the design, generates the final image, and uses the provider’s own programming path to place it on the FPGA. In the intended model, the customer can use the permitted region but cannot directly generate, program, or replace the final hardware image.
Those steps establish a contract about control. The customer is promised useful reconfigurable capacity, while the provider keeps the shell, host connection, and sensitive device functions outside the customer’s authority. The contract is stronger than “the customer usually behaves.” It depends on the assumption that the capabilities available inside an approved design are themselves bounded. If a design can later ask the configuration engine to modify hardware that was not part of the approved image, then the provider has checked one state of the device while the customer can cause another.
This is the distinction that gives the study its force. The paper does not say that cloud providers have no defenses. It describes design checks, provider-controlled bitstream generation, hypervisor-mediated programming, and runtime monitoring of conditions such as power and temperature. Those defenses address real risks. The problem is that they were not all designed around a tenant-controlled path to low-level configuration and debugging features. A rule saying that a powerful primitive belongs in a static part of the design is not the same as a physical mechanism that makes the primitive unreachable from a reconfigurable customer region.
The defenses also operate at different times. Before deployment, the provider can inspect the customer’s design for forbidden structures and functional violations. During deployment, the provider can keep final image generation and programming under its control. After deployment, monitoring can look for suspicious power, temperature, or clock behavior. These controls complement one another, but they do not inspect the same object. A design check examines what the customer submitted; a configuration-engine transaction can change what the device is doing later. That difference in time is the opening through which the study’s escalation passes.
The paper’s four-fence description makes the mismatch easier to see without requiring a detailed knowledge of Amazon’s implementation. The first fence is design verification. The second keeps bitstream generation with the provider. The third prevents the customer from directly programming the final image. The fourth watches the running device and can react to abnormal conditions. The expected boundary is that all meaningful hardware changes must pass through at least one of these controls. The finding challenges that expectation by identifying a path from an approved running design to a lower-level configuration interface that was not effectively filtered.
The diagram is a map of capabilities, not a claim that every arrow was used destructively in the cloud. Ordinary access ends with a running design inside the provider’s deployment model. The concern begins when that running design can reach the Internal Configuration Access Port, or ICAP. ICAP is an interface to the FPGA’s configuration engine. From there, the study describes a further path to an internal Joint Test Action Group, or JTAG, interface. JTAG is normally associated with testing and debugging; in this setting it can reach security-relevant device state, including one-time-programmable eFuses.
The question the hardware raises
The paper reports that a regular cloud customer could obtain ICAP control on the evaluated AMD devices, then use that control to activate an internal JTAG path. The resulting capabilities include reading configuration state and writing new hardware configuration in a reachable region. The authors demonstrated the non-destructive path on AWS F1 and F2 instances and used a small ring oscillator to show that circuitry normally rejected by provider checks could be introduced after deployment. They did not program irreversible eFuse changes on Amazon hardware.
The eFuse stage is why the finding is more than another example of an imperfect design filter. E-fuses store device-specific security settings and key material, and their programmed state cannot simply be rolled back with a reset. In a controlled local environment, the researchers verified the logic of a scenario in which an attacker-controlled encryption and authentication policy could prevent the provider from producing an accepted configuration for an affected region. The paper calls this a form of ransomware for FPGA hardware: the object held hostage is not a customer’s file, but the provider’s ability to reconfigure its own compute resource.
The persistence matters because cloud operations normally assume that a failed or compromised instance can be reset, reprovisioned, or replaced through the provider’s control plane. A temporary change to customer logic may disappear when the next image is loaded. A one-time security-state change is different: the reset and reprovisioning machinery may itself depend on the policy that was altered. In that sense, the final stage targets the provider’s recovery authority. It is a change in who controls future changes, not simply another change to the current workload.
That wording needs care. The study establishes a privilege-escalation path and reports cloud access sufficient for non-destructive reads and reconfiguration experiments. The irreversible cloud write and ransom demand are a locally validated threat scenario, not a destructive AWS incident. The paper also reports that AWS and AMD were notified, that AWS deployed mitigations before publication, and that AMD alerted customers using similar devices. The case is therefore both a warning about a pre-mitigation architecture and a record of a vulnerability that the vendors say was addressed.
The distinction between those evidence levels is part of the finding, not a footnote. The cloud experiments show that an ordinary customer path could reach capabilities the provider intended to reserve. Local testing shows how the eFuse mechanism could turn that access into persistence without risking Amazon equipment. The paper’s impact discussion then asks what the loss of an affected region could mean for capacity and recovery. Each step answers a different question, so none should be silently substituted for another: access is not the same as irreversible damage, and a plausible scale estimate is not a measured outage.
The deeper issue remains current beyond this particular patch. Cloud isolation is often described at the level of accounts, virtual machines, APIs, and submitted images. A programmable accelerator adds another layer: the physical device has its own configuration, debug, identity, and non-volatile security state. If those controls can be reached from tenant hardware after the provider’s last verification step, the isolation boundary has fallen through the hardware control plane. Understanding exactly where that happens requires looking at the shell, the reconfigurable regions, and the asymmetric topology of the device.