What the Evidence Shows—and Where It Stops
The Silicon Heist study is strongest when its claims are kept at their proper evidence level. This chapter focuses on that boundary: which capabilities the researchers observed on Amazon’s F1 and F2 instances, which irreversible behavior they validated on local hardware, which adjacent path AMD reportedly confirmed, and which impact estimates remain scenarios. That distinction supports a practical judgment: the finding is serious because a tenant could reach the hardware control plane, not because every possible consequence was destructively demonstrated in a live cloud.
What the study actually demonstrates
The evidence has several layers, and they answer different questions. The first layer is the cloud case study. The researchers report that a regular customer design could obtain ICAP control in the evaluated AWS flow and use that control to activate an internal MASTER_JTAG path. They used the resulting access to read configuration and device state and to perform non-destructive experiments on F1 and F2 instances. This establishes remote reachability of capabilities that the provider intended to keep outside ordinary customer control.
The second layer is the post-deployment modification demonstration. The researchers used ICAP access to introduce a small ring oscillator, a circuit normally rejected by the provider’s design checks, and observed its activity through a counter. That experiment shows that the effective hardware state could be changed after the original verification step. It does not establish that every malicious circuit would evade every runtime defense, but it does establish the central timing failure: the running design could cause configuration changes that were not present in the checked artifact.
The third layer is the eFuse read case. Through the internal JTAG path, the researchers scanned the eFuse memory on the cloud devices. They report that all registers except the AES key were readable. They also read FUSE_DNA, the factory-programmed device identifier that AWS explicitly kept from users. The result is a confidentiality and fleet-mapping concern even without an irreversible write. If repeated instance launches reveal the same identifier, an observer can recognize a physical device across runs and build a picture of the fleet’s allocation or reuse.
The study’s claim about fingerprinting should be read narrowly. The authors describe the method as fully accurate for the evaluated setup. That is a result about the tested devices and the information exposed through them. It is not a guarantee that every cloud FPGA presents a stable, readable identifier or that a provider’s entire supply chain can be reconstructed from it. The paper discusses device-type, supply-chain, and lifecycle inferences as possible uses of the information, not as completed measurements of Amazon’s inventory.
The fourth layer is local validation of the destructive mechanism. The researchers used a controlled local environment to read and write eFuse state and to verify the logic of the proposed lockout. They did not program the eFuses on Amazon’s devices because the change would be permanent. Local validation is appropriate for a destructive hardware experiment, but it means the article must not silently upgrade “validated locally” into “executed against AWS.” The cloud evidence demonstrates reachability and non-destructive behavior; the local evidence demonstrates how that reachability could become persistent.
The fifth layer is an adjacent path identified during disclosure. AMD reportedly told the researchers that ICAP access could also be used to instantiate a STARTUP primitive with access to non-volatile flash storing the FPGA boot image. Overwriting or erasing that image could require reprovisioning.