When FPGAs Meet the Cloud: Hidden Security Risks in AI Acceleration
How residual data in shared FPGA infrastructure can expose images, AI workloads, and cryptographic keys, even after a tenant logs out.
Join Bharadwaj Madabhushi, PhD, Member of Technical Staff at AMD, for a technical webinar examining a largely overlooked security risk in multi-tenant FPGA systems: what happens to sensitive data after a workload ends?
Through practical experiments on FPGA hardware and a public cloud testbed, this session shows how data left in DRAM, Block RAM and Ultra RAM may remain recoverable by another tenant. It also examines debugger-based attacks capable of bypassing operating systems, hypervisors and conventional memory-protection mechanisms.
When a tenant logs out, does the hardware actually forget?
FPGAs are increasingly being used as shared cloud accelerators for artificial intelligence, machine learning, cryptography and high-performance computing.
Their reconfigurability, performance and energy efficiency make them highly attractive for cloud deployments. But the same physical hardware may be reassigned from one customer to another within minutes.
That creates a critical question:
Is the previous tenant’s data securely erased before the next tenant gains access?
What You Will Learn:
During this webinar, you will learn:
- Why FPGAs are becoming important accelerators for AI and machine-learning workloads
- How multi-tenant FPGA cloud architectures assign compute and memory resources
- Why conventional memory-protection mechanisms may protect active tenants but fail after termination
- How residual data can remain in FPGA-connected DRAM, Block RAM and Ultra RAM
- How researchers recovered image data and machine-learning model information after a tenant session ended
- How an AES-128 cryptographic key was reconstructed from residual Block RAM
- How JTAG and Xilinx Virtual Cable access can enable bare-metal code to bypass the operating system and hypervisor
- Why common sanitisation methods such as power cycling and full-memory wiping are difficult to use in live cloud environments
- How fine-grained sanitisation can reduce the risk without disrupting other tenants
SIGNUP & WATCH NOW
Real Experimental Findings
Data recovered after the tenant had logged out
The research presented in this webinar includes multiple practical demonstrations.
FPGA DRAM residue
A new tenant was able to access data belonging to a previous tenant after the original session had terminated.
The recovered information included:
- Original data values
- Identifiable image contents
- References to a ResNet-50 machine-learning model
- Residual data recovered from a public FPGA cloud testbed approximately 20 minutes after logout
Cryptographic key recovery from Block RAM
An AES-128 kernel generated and stored an expanded encryption-key schedule in FPGA Block RAM.
After the victim kernel exited, an unrelated attacker kernel accessed the same physical memory and recovered the complete 176-byte key schedule. The original 128-bit AES key could then be reconstructed.
The attack was also reproduced on an Intel Cyclone V device, suggesting that on-chip memory remanence may extend beyond a single vendor or FPGA family.
Debugger-based memory access
The research also demonstrates how bare-metal code loaded through JTAG or Xilinx Virtual Cable can access memory directly.
In the tested configuration, the attacker could read:
- Memory belonging to an active Xen hypervisor
- Memory belonging to a running guest virtual machine
- Data remaining after the guest virtual machine had been destroyed
The memory extraction continued even after the operating system generated warnings and entered a kernel panic.
Why Existing Protection May Not Be Enough?
Memory-protection units, hypervisors and operating-system isolation are designed primarily to control access while workloads are active.
They do not necessarily erase the data when a tenant’s session ends.
This creates three distinct attack surfaces:
FPGA-connected DRAM
A memory region may be reassigned to another tenant without first being securely cleared.
On-chip Block RAM and Ultra RAM
These high-speed memories may retain model weights, intermediate values, keys and application data after a kernel exits.
Debug and monitoring interfaces
JTAG, UART and virtual debug interfaces are useful during development but can create powerful attack paths when insufficiently restricted in deployed systems.
Why Sanitisation Is Difficult?
The apparent solution is to erase memory before reassigning it. In practice, that is more complicated.
- Power cycling clears memory but takes the complete device offline
- Full-region wiping may erase data belonging to active tenants
- Address-space randomisation scatters application data across non-contiguous memory
- Hardware-assisted techniques may require changes to the memory controller
- Software-only sanitisation can leave a delay between termination and cleanup
- FPGA on-chip memory is not always tracked by the operating system or hypervisor
A practical solution must therefore be fast, precise and tenant-aware.
Introducing SCRUM
Secure Cleanup of Residual User Memory
The webinar presents SCRUM, a lightweight kernel-level sanitisation approach designed to clear a tenant’s memory footprint when the session terminates.
Instead of wiping an entire memory region, SCRUM tracks and clears only the memory used by the departing tenant.
In experimental testing:
- Up to 3GB of memory was sanitised
- Tests were conducted with address-space randomisation enabled and disabled
- The system was tested under multicore memory contention
- Cleanup completed in under eight seconds in the tested worst-case condition
- Sanitisation ran on a single processor core
- Other cores remained available for active tenants
The results demonstrate that precise memory sanitisation can be implemented without shutting down the full FPGA platform.
Who Should Attend?
This webinar is relevant for:
- FPGA and RTL design engineers
- Embedded Linux developers
- Cloud infrastructure architects
- AI accelerator engineers
- Hardware-security researchers
- Firmware and hypervisor developers
- DevOps and platform-engineering teams
- Cryptography and secure-computing professionals
- Researchers working on heterogeneous and reconfigurable computing
- Organisations deploying sensitive workloads on shared accelerator infrastructure
Key Takeaways
By the end of this session, attendees will understand:
- Why shared FPGA systems must securely erase data between tenants
- Where residual data can remain inside FPGA-based platforms
- Which protection mechanisms work only while a tenant is active
- How practical data-extraction attacks can be performed
- Why debug interfaces require strict access control
- What cloud and FPGA platform designers can do to reduce the risk
- How fine-grained sanitisation can improve security without excessive downtime
Speaker
Member of Technical Staff, AMD