Ravan Nazaraliyev

Ravan Nazaraliyev

Ph.D. Student, Computer Science
University of California, Riverside

Research

GPUs used to belong to one user at a time. Today they are shared: cloud providers split a single GPU between tenants, and large jobs run across many GPUs connected by fast links. Sharing hardware means sharing its side effects. My work looks at what one user can learn about, or do to, another user through those shared parts: the memory, the memory controller and the links between GPUs.

PAGE404: Breaking GPU isolation through page migration

IEEE S&P 2027 Code

NVIDIA's GH200 pairs a CPU and a GPU that share memory. To keep data close to whoever is using it, the hardware moves memory pages between CPU and GPU memory on its own. The GPU can also be split into isolated slices with Multi-Instance GPU (MIG), so different customers can run side by side.

We found that page migration is not fully isolated between those slices. By watching how long migrations take, or by forcing evictions, one tenant can observe another. We used this to build a covert channel between two MIG slices, and two side-channel attacks against a victim running a large language model: one tells which model the victim is running, and one estimates the length of the victim's prompt. We reported the issue to NVIDIA.

Not so Refreshing: Attacking GPUs using a Rowhammer mitigation

USENIX Security 2025 Paper Code

Rowhammer is a DRAM bug: accessing one memory row over and over can flip bits in nearby rows. Newer memory defends against it with Refresh Management (RFM), which issues extra refreshes when a bank is accessed too often. While a refresh runs, the bank is busy.

That busy time is visible. On GPUs with GDDR6 memory, we showed that an attacker can tell when RFM fires and use it as a timing signal. With it we built a covert channel of over 50 KB/s per bank, fingerprinted which application another user was running (up to 95% F1) and what was being rendered in Blender (up to 98% F1). We also turned it into a denial-of-service attack that slows a victim down by 4.8x on average. In short, a defense added for security creates a new leak.

NVBleed and Beyond the Bridge: Leaks over NVLink

ACM CCS 2026 Paper  ·  IEEE SEED 2024 Paper

Servers with several GPUs connect them with NVLink, a high-speed interconnect. When two jobs send data over the same link, they slow each other down. In Beyond the Bridge we showed that this contention is enough to build a 45.5 kbps covert channel between GPUs and to fingerprint applications, without special privileges.

NVBleed goes further. We reverse engineered how NVLink works and found two leaks: timing from contention, and NVLink performance counters that ordinary users can read. These give a covert channel of over 70 kbps, application fingerprinting across 18 HPC and deep learning workloads (97.8% F1), and identification of 3D characters rendered in Blender. We also showed the leak across virtual machines on Google Cloud, and discussed defenses such as restricting counter access.

PRACtical: Making Rowhammer defense cheaper

arXiv 2025 Paper

DDR5 adds Per-Row Activation Counting (PRAC): the memory counts how often each row is opened and asks for time to recover when a row gets close to the danger zone. It works, but it costs performance. Updating the counter slows down every row close, and recovery stalls the whole memory channel even if only one bank is under attack.

PRACtical fixes both problems with the same security guarantee. Counter updates overlap with work in other subarrays, and recovery pauses only the banks that need it. In simulation this gives an average 8% speedup (up to 20%) over the previous best design and uses 19% less energy.