The Isolation Contract Inside a Cloud FPGA
In the Silicon Heist study, the important boundary is not between two software processes but among several owners of one physical programmable device. This chapter focuses on the AMD UltraScale+ architecture used by Amazon’s EC2 F1 and F2 FPGA instances: what the customer design controls, what the provider shell must retain, and how the device’s regional layout limits or enables reach. The practical value of this map is simple: it lets us judge later access claims by asking which physical region and which owner’s state a capability can actually affect.
What the customer is actually renting
An FPGA is a piece of hardware whose logic can be rearranged after manufacture. Its fabric contains small configurable logic elements for implementing Boolean functions, flip-flops for holding state, blocks of memory, specialized arithmetic or signal-processing units, and programmable routes connecting them. A design determines how those resources behave and how signals move among them. When a cloud customer “runs” an FPGA workload, the service is therefore loading a hardware arrangement into a physical device, not starting a conventional software process inside an abstract computer.
That distinction creates two kinds of ownership. The customer owns the intent and logic of the workload: perhaps a video-processing pipeline, a machine-learning accelerator, or a scientific computation. The cloud provider owns the FPGA, the board, the host connection, and the service that decides how customer logic reaches the fabric. The provider cannot simply give the customer unrestricted access to every configurable resource. If it did, a customer design could interfere with the infrastructure that loads it, communicates with the host, or supports another service function.
Amazon’s cloud-FPGA model addresses this by reserving part of the device for a provider-supplied shell. The shell is hardware that sits alongside the customer’s logic. It interfaces with the device’s PCI Express connection, manages communication with the host system, and participates in configuring the customer portion. The customer design is placed in a reconfigurable region that the shell can load and replace while the provider-controlled part remains in place. From the customer’s point of view, the shell is the stable service boundary: it is what turns a piece of programmable silicon into something that can be rented through a cloud API.
The shell must also be treated as an owner of state. It has its own logic, routes, interfaces, and configuration responsibilities. The customer is not supposed to instantiate resources in the shell’s reserved region or rewrite the shell’s assumptions about how images are loaded. This is why the study’s isolation question is more specific than “can a customer program an FPGA?” Customers are meant to program a defined portion of an FPGA. The security question is whether the permitted programming path can reach the machinery that controls portions outside that definition.
The normal deployment workflow reinforces this division. A customer develops a design with AMD’s tools and the cloud provider’s hardware-development kit. The toolchain turns the design description into a placed and routed representation, often retained as a design checkpoint. That checkpoint is sent to a provider-controlled service, which performs verification and creates the final image used by the cloud instance. The provider then programs the device through its own deployment path. In the intended arrangement, the customer can influence the logic that occupies the assigned region but does not receive unrestricted control over final bitstream generation or device programming.
This workflow is useful because it separates responsibilities at each stage. The customer is responsible for a design that fits the permitted region and performs the desired computation. The provider’s verification service is responsible for rejecting designs that would create unsafe or unsupported structures. The provider’s programming path is responsible for loading an approved image onto the physical FPGA. The shell is responsible for making the customer region usable without surrendering the host-facing infrastructure. The isolation contract is the agreement among all four responsibilities.
Partial reconfiguration makes the service flexible. Instead of stopping the entire FPGA and replacing every configuration element, the provider can update a selected region while the rest of the design continues operating. A customer can therefore change an accelerator or share a physical resource without treating the whole device as disposable. But the same feature means that configuration remains a live activity after initial startup. The device has a continuing transition path, not one permanent loading event. Security depends on who may initiate that transition and which regions the transition can address.
The lifecycle has a useful sequence of states. The empty device first receives the provider shell. The shell then accepts an approved customer design, and the customer region becomes an active part of the larger circuit. Later, a new customer image may replace that region without replacing the shell. At each transition, the provider expects the incoming configuration data to be the only thing that changes the permitted state. That expectation is safe only if the configuration engine itself remains under the provider’s authority. If customer logic can submit its own configuration commands, the provider no longer controls the complete transition between “approved design” and “running design.”
The distinction between a logical allocation and a control allocation is important. The customer may be assigned a region of logic, but the interfaces that configure that region can be physically adjacent to, or connected with, resources outside it. A boundary drawn around lookup tables and routing resources does not automatically enclose every path that can address them. The provider therefore has to reason about reachability in two dimensions: where a customer design is placed, and which control engines, debug paths, or neighboring regions that placement can influence. The second question is easy to miss because it is not visible in the service’s ordinary allocation language.
For a software engineer, the closest analogy is a process with a privileged service interface. A tenant may be allowed to submit jobs to the service, but not to rewrite the service’s memory manager or replace the hypervisor. The analogy becomes imperfect at exactly the point that matters here. A hardware design is not merely a passive request delivered to a privileged component. Once instantiated, it can contain interfaces and logic that continue operating inside the same physical fabric. If one of those interfaces can reach the configuration engine, the tenant may acquire a new way to change the device after the provider’s original checks have completed.
The provider’s isolation model succeeds when the customer region is both useful and bounded: the customer can configure its assigned logic, while shell resources and higher-privilege device controls remain inaccessible. It fails if the customer can cause a new configuration interface to become active in a reachable region, because then “the customer region” is no longer only a destination for approved configuration. It becomes a possible source of further configuration commands. The difference is a change in control flow, not a change in the customer’s billing plan or API permissions.
Why the device is not one flat region
The AWS devices studied by Klix and colleagues use AMD’s stacked-silicon-interconnect technology. In this design, multiple FPGA dies are packaged together so that they appear to software and to the user as one larger device. The paper describes the target F1 and F2 devices as containing three Super Logic Regions, or SLRs. An SLR is best understood here as a substantial physical region with its own local hardware resources, including a configuration engine, an ICAP, and JTAG circuitry. The package presents a unified accelerator, but the control machinery is not literally one undivided block.
The SLRs are linked by a configuration daisy chain. Configuration begins in a primary region and is propagated toward downstream regions. The dependency is directional: a region can reach regions later in the chain, but it cannot use that same chain to reach a region earlier in the chain. This asymmetry matters more than the raw count of regions. It determines what a compromised configuration path can touch and what remains outside its reach.
The provider shell occupies important resources in the lower regions of the F1 and F2 layouts described by the study, including the ICAP locations used by the shell. The remaining customer-visible region includes an ICAP in SLR2. The paper identifies the F1 device as a VU9P and the F2 device as a VU47P, but the security argument does not depend on treating those part numbers as interchangeable with every AMD FPGA. It depends on the specific fact that a customer-reachable configuration resource existed in a secondary region while critical shell logic occupied other regions.
This layout produces a bounded but meaningful result. Access to the secondary region does not automatically give a customer control of the provider shell, the host interface, or every SLR. The researchers state that their practical attacks were limited to resources within or reachable from SLR2. At the same time, the region is not harmless simply because it is not the shell’s primary location. Its local configuration engine can change the fabric in that region, and the directional chain can make downstream reach more significant than a simple “one-third of the chip” estimate suggests.
The chain is also a hidden dependency in the device’s lifecycle. A configuration action in one region can affect how later configuration data is propagated. The study reports that making an additional ICAP usable in a secondary SLR required the researchers to account for a broken daisy-chain connection and for the state of the affected region during reconfiguration. The details are implementation-specific, but the architectural lesson is general within the case: reconfiguration is not an isolated write to a neutral memory array. It is a sequence that depends on placement, routing, ordering, and the state of neighboring control engines.
This gives the F1/F2 architecture two properties that must be held together. First, it limits the blast radius: the tested path did not automatically reach every shell component or every region. Second, it creates a non-obvious route from a local capability to a larger control relationship: a secondary engine can affect configuration work that is meaningful beyond the customer’s immediate logic, even when it cannot travel backward to the primary region. A provider that measures risk only by the percentage of fabric assigned to a tenant may therefore miss the more important variable—whether that assignment contains an active control interface.
The diagram shows why the provider shell and the configuration engine belong in the same security model. The shell uses an engine to load customer logic, but the customer design is also placed inside the fabric that contains regional engines. Under normal operation, the shell is the sole trusted path for the relevant configuration work. If a tenant design can activate another engine or talk to it directly, the relationship changes: the customer is no longer only a client of the shell; the customer design has become a participant in the device’s control plane.
That relationship also explains why a cloud provider cannot reason about isolation solely from the customer’s visible region. A region is a physical allocation, not necessarily a complete authority boundary. Its wires may connect to neighboring logic. Its configuration engine may have a defined relationship with engines elsewhere. Its primitives may affect state that outlives the current workload. The provider must know not only where customer logic is placed, but what interfaces that placement makes reachable and what those interfaces can ask the hardware to do.
The Silicon Heist study found the key discrepancy in this architecture. AMD guidance described ICAP and related configuration components as resources that should remain in a static part of the design. Yet the authors report that the tools did not impose a hard limitation preventing an additional ICAP in an appropriate secondary region, and the evaluated AWS verification path did not prohibit its instantiation. A static-region recommendation describes intended placement; it does not, by itself, create an unbreakable boundary around the configuration engine.
That discrepancy is easier to understand once the device is viewed as a set of owners and transitions. The customer submits a design. The provider checks and programs it. The shell preserves the service interfaces. The FPGA fabric continues to operate and can support partial updates. Each step is reasonable in isolation. The failure appears where a customer-controlled region has a path to a resource whose authority extends beyond that region. The next question is therefore not whether the FPGA can be reconfigured—it plainly can—but whether a running design can invoke the configuration machinery that the provider expected to keep under its own control.