GPU.zip: On the Side-Channel Implications of Hardware-Based Graphical Data Compression

GPU.zip: On the Side-Channel Implications of Hardware-Based Graphical Data Compression

Speakers: Yingchen Wang; Riccardo Paccagnella; Zhao Gang; Willy R. Vasquez; David Kohlbrenner; Hovav Shacham

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=FQrCpZsN8Cs

Overview

The talk "GPU.zip: On the Side-Channel Implications of Hardware-Based Graphical Data Compression" by Yingchen Wang and colleagues introduces a novel and insidious form of side-channel attack that exploits hardware-based graphical data compression within modern GPUs. This work challenges long-held assumptions about the visibility and mitigability of compression side channels, revealing a new frontier for privacy and security vulnerabilities. Unlike traditional compression side channels, which typically target software-visible and well-documented compression algorithms, GPU.zip focuses on a type of compression that operates silently within the GPU's microarchitecture, is entirely transparent to software, and whose algorithms are proprietary and undocumented by vendors.

The research highlights a critical "missing hardware-software contract" in modern computing, where hardware optimizations designed for performance (like graphical data compression) inadvertently create exploitable information leakage channels. The speakers demonstrate that the compressibility of graphical data, which often depends on the content being rendered, leaves observable microarchitectural traces. These traces, such as variations in memory controller traffic and rendering time, can be leveraged by a collocated attacker to infer sensitive on-screen information, even bypassing robust browser security mechanisms like the Same-Origin Policy. The implications are profound, extending the threat landscape to virtually any visual data processed by a GPU, from email content and credit card numbers to browsing history.

This talk is particularly significant because it uncovers a previously unaddressed attack surface that exists in nearly all modern GPUs. By meticulously reverse-engineering proprietary compression algorithms and demonstrating a practical end-to-end pixel-stealing attack, the researchers underscore the urgent need for GPU vendors to provide mechanisms for software to control or disable this compression when handling sensitive data. The findings not only expose a new class of vulnerabilities but also motivate a broader re-evaluation of how hardware optimizations interact with security boundaries, urging a more explicit and secure contract between hardware and software layers.

Background

▶ Watch: Introduction to GPU.zip and unique compression side channel (0:00)

Compression has long been recognized as a potential source of information leakage, a principle famously exploited by attacks like CRIME (Compression Ratio Info-leak Made Easy) over a decade ago. The CRIME attack demonstrated how an attacker with chosen-input capabilities could infer secret cookies in secure network requests by observing variations in the length of TLS-compressed network packets. If an attacker's input happened to repeat a partial user secret, the resulting compressed data would be smaller, allowing for brute-force extraction of the secret. Subsequent attacks have similarly abused software-visible compression side channels, but a crucial saving grace has always been that compression was typically observable and could, in principle, be controlled or disabled by software.

The problem addressed by GPU.zip stems from a different type of compression: graphical data compression, a feature ubiquitously deployed in almost all modern GPUs. This compression scheme emerged as a necessary optimization to address the burgeoning demands of higher screen resolutions and refresh rates. As devices like Google Pixel phones demonstrate, the amount of pixel data that must be transferred per second has drastically increased across generations. While DRAM technology has advanced, the sheer volume of data required for GPU rendering can still create a significant memory bottleneck. To alleviate this, GPU vendors developed and integrated graphical data compression directly into the GPU microarchitecture.

Crucially, graphical data compression differs fundamentally from traditional software compression. While software compression (e.g., deflate for .zip files) aims to reduce memory usage by creating a more compact representation of data, graphical data compression primarily seeks to reduce memory bandwidth usage. It achieves this by transferring fewer bytes across the memory bus for the same visual effect, often at the cost of potentially higher memory usage for storing auxiliary metadata. This compression is lossless, meaning the original image can be perfectly reconstructed.

The critical distinction is that this graphical compression is software transparent – it kicks in automatically without any explicit request or awareness from the software application. Furthermore, it is microarchitecture-specific and undocumented, with each GPU vendor implementing its own proprietary algorithms. This lack of transparency and documentation makes it incredibly challenging for defenders to understand, predict, or mitigate its security implications, as they cannot make assumptions about the compression algorithm in use or how it might interact with sensitive data.

Key Findings

▶ Watch: Motivation for hardware graphical data compression (2:10)

The research presented in GPU.zip uncovers several critical findings that redefine our understanding of compression side channels and GPU security:

1. Ubiquitous and Undocumented Hardware Compression: Graphical data compression is a pervasive feature present in virtually all modern GPUs. However, these algorithms are proprietary, vendor-specific, and completely undocumented, making it impossible for software developers or security researchers to know how specific data patterns will be compressed or to anticipate potential side channels.
2. Software Transparency as a Security Risk: The compression process is entirely transparent to the software stack. Applications render graphics, and the GPU silently decides whether and how to compress the data, without any explicit command or notification to the operating system or application. This transparency means software cannot opt-out of compression for sensitive data.
3. Observable Microarchitectural Traces: Despite its transparency, graphical data compression leaves distinct, data-dependent traces in the GPU's microarchitecture. Specifically, the compressibility of a rendered surface directly impacts memory controller traffic (DRAM read/write operations) and Last Level Cache (LLC) occupancy. Highly compressible data results in significantly less memory traffic and potentially different cache behavior compared to non-compressible data.
4. Time-Based Side Channels: These microarchitectural differences translate into observable timing variations. Surfaces that are highly compressible are rendered faster because they require less data transfer across the memory bus. A collocated attacker can measure these rendering time differences to distinguish between compressible and non-compressible patterns.
5. Successful Reverse Engineering: The researchers successfully reverse-engineered several proprietary graphical data compression algorithms, including those used by Intel's 8th and 11th generation integrated GPUs (based on prediction and residue) and AMD's more complex Delta color compression scheme. This was achieved using custom tooling that allowed for chosen-ciphertext-like attacks against the GPU's black-box compression engine.
6. End-to-End Pixel-Stealing Attack: The most significant finding is the demonstration of an end-to-end pixel-stealing attack against web browsers. By exploiting the timing side channel created by graphical data compression, a malicious JavaScript attacker can bypass the Same-Origin Policy (SOP) and extract individual pixels from cross-origin iframes. This attack exploits how browsers offload SVG filter stack rendering to the GPU, turning a previously mitigated attack vector into a live threat.
7. Missing Hardware-Software Contract: The existence and exploitability of GPU.zip highlight a fundamental flaw: the absence of a clear security contract between hardware and software. Hardware optimizations, while beneficial for performance, can introduce unforeseen security vulnerabilities when not designed with security boundaries and information flow in mind.

Technical Deep Dive

▶ Watch: Distinction: Graphical vs. traditional software compression (3:20)

The core of GPU.zip lies in understanding how graphical data compression works and how its internal mechanics expose side-channel leakage. The paper provides a concrete example using Intel's 8th generation integrated GPU. When the GPU renders a surface, it breaks it down into tiles, typically multiples of the physical page size (e.g., 4 KB, or 32x32 pixels) to improve memory locality. To further optimize, each tile is then subdivided into smaller blocks. On the Intel iGPU, each block consists of two cache lines, representing 4x8 pixels.

The proprietary compression algorithm then operates on these individual blocks. If a block is deemed "compressible" (e.g., containing uniform color or predictable patterns), the GPU compresses it from its original two cache lines into a single cache line, padding the remaining space with zeros. If the block is not compressible, it remains in its original two-cache-line format. To manage this variable-length storage, an auxiliary surface is attached. This surface contains metadata (e.g., 2 bits per block) indicating whether a given block is stored in its compressed or original representation. When the GPU needs to read the image, it consults the auxiliary surface, reads only the non-zero parts, and losslessly decompresses the data back to its original form. While many variants exist across vendors, the high-level principle is consistent: reduce memory bandwidth by transferring fewer bytes, often at the cost of higher memory usage for the auxiliary surface.

The "software transparent" nature of this compression is critical to its security implications. When a user or application (e.g., via OpenGL or Vulkan) requests to render a surface, the graphics driver (e.g., Mesa) communicates with the kernel driver. The kernel driver allocates memory for the surface, and critically, the GPU itself silently performs the compression after the rendering job is submitted. The application and even the kernel driver are not explicitly aware that compression has occurred or what its outcome is. This means software cannot make informed security decisions based on the compression status.

The researchers observed significant differences in compression algorithms across vendors and even generations. For instance, AMD's compression was found to be more aggressive than Intel's, and Intel's algorithms evolved between 8th and 11th generations. This vendor-specific, undocumented nature posed a significant challenge for security research, as the same input pattern could yield vastly different compressed representations on different platforms. To overcome this, the team developed i915 tools, a suite designed for reverse engineering graphical data compression algorithms. This tool provides three key functionalities: dump (to capture compressed surfaces), decode (to attempt to interpret compressed data), and twig (the most powerful). The twig functionality allows users to create specific surfaces using an expression language, automatically locate the GPU-created compressed surface, and then "tweak" individual pixels within that compressed surface (e.g., changing a byte from 7f to 6f). The tool then asks the GPU to decompress the tweaked surface and reports the resulting changes in the decompressed output. This process effectively implements a chosen-ciphertext attack, treating the GPU compression algorithm as a black box and, through interaction, gathering enough information (like linear equations) to reverse-engineer its internal logic. Using i915 tools, they successfully reverse-engineered Intel's prediction and residue-based scheme and AMD's Delta color compression.

The leakage model for GPU.zip is based on observable microarchitectural traces. The researchers demonstrated that surfaces with different compressibility characteristics leave distinct ephemeral traces in the memory controller and permanent traces in the Last Level Cache (LLC). By setting up a rendering experiment where the GPU repeatedly writes and reads a surface with either a compressible (e.g., solid black) or non-compressible (e.g., random noise) pattern, they monitored DRAM read and write performance counters. They observed that rendering a compressible pattern resulted in exactly half the amount of traffic transferred across the memory controller compared to a non-compressible one. Since the memory controller has a maximum bandwidth limit, less traffic directly translates to a faster rendering time. This difference in rendering time, measurable by a collocated attacker, allows for distinguishing between compressible and non-compressible patterns. Similar leakage was observed via LLC occupancy, as detailed in their paper.

The end-to-end attack demonstrated in the paper is a pixel-stealing attack within a web browser, bypassing the Same-Origin Policy (SOP). This attack builds upon prior work by Paul Stone (Black Hat 2013) and Adis Atrisco, who showed how timing side channels could be exploited via SVG filters executed on the CPU. In response, Chrome and other browsers implemented mitigations, primarily executing SVG filters in constant time and offloading graphical operations to the GPU, hoping to eliminate the attack surface. However, GPU.zip proves this mitigation insufficient.

A malicious host webpage can embed a cross-origin iframe and use an SVG filter stack to isolate, binarize, and expand a single pixel from the cross-origin content into a large region of either solid black or solid white. For example, if the target pixel is black, the filter stack generates many black surfaces during rendering. If the target pixel is white, it generates many turbulent (non-compressible) surfaces. Because black surfaces are highly compressible, their rendering triggers significantly less DRAM traffic and thus completes faster. By measuring the SVG filter stack's rendering time, the malicious JavaScript attacker can infer the color of the isolated pixel. This process can be repeated pixel by pixel to reconstruct an entire image. The researchers demonstrated this with a user fingerprinting attack on a Wikipedia username displayed within a cross-origin iframe. By applying the filter stack and measuring rendering times, the attacker could extract the username pixel by pixel, entirely bypassing the Same-Origin Policy.

Demo / Proof of Concept

▶ Watch: Detailed explanation of Intel iGPU compression scheme (4:00)

The talk effectively showcased two main proof-of-concept elements: the i915 tools for reverse engineering and the end-to-end pixel-stealing attack.

The i915 tools represent a crucial methodological contribution. The speaker demonstrated the twig functionality, which allows for extensive interaction with the black-box compression algorithm. Users can define a surface using an efficient expression language (e.g., specifying a gradient surface). The tool then automatically identifies the corresponding compressed surface generated by the GPU in the process address space. The twig feature allows users to directly modify (tweak) specific pixels within this compressed representation, for example, changing a byte from 7f to 6f. After tweaking, the tool instructs the GPU to decompress the modified surface and displays the decompression result. By observing how single-byte tweaks in the compressed data lead to deviations in the decompressed image, researchers can infer the internal logic of the compression algorithm. This "chosen-ciphertext attack" methodology was instrumental in reverse-engineering the proprietary Intel 8th and 11th generation, and AMD Delta color compression schemes.

The pixel-stealing attack served as the culmination, demonstrating the real-world exploitability of GPU.zip. The scenario involved an attacker sending a phishing email containing a link to a Wikipedia page with the user's username displayed. Due to the Same-Origin Policy, the attacker's malicious JavaScript on a hosted page cannot directly read the username from the Wikipedia iframe. However, the attacker crafts an SVG filter stack that, when applied to the cross-origin content, isolates and binarizes a single pixel of the username. Depending on whether this pixel is black or white, the SVG filter stack generates either highly compressible (many black) or less compressible (many turbulent) graphical surfaces, respectively. The GPU's hardware compression then processes these surfaces, leading to measurable differences in rendering time. By precisely measuring the rendering time of the SVG filter stack, the attacker can infer the color of that single pixel. This process is then iterated, pixel by pixel, to reconstruct the entire username, effectively bypassing the Same-Origin Policy solely by observing screen rendering times. The talk visually presented the raw Wikipedia username, its binarized version, and the final reconstruction achieved through the GPU.zip attack.

Defensive Implications

▶ Watch: Demonstration of software-transparent compression activation (6:00)

The GPU.zip research exposes a fundamental flaw in the current security model of modern computing, characterized as a "missing hardware-software contract." The primary defensive implication is a strong call to action for GPU vendors.

The ideal mitigation would be for GPU vendors to provide a granular, software-accessible knob or API that allows applications to explicitly disable hardware-based graphical data compression for specific memory regions or surfaces known to contain sensitive data. This would empower software developers to make informed security decisions, ensuring that private information is not inadvertently leaked through microarchitectural side channels. Without such a mechanism, software remains blind to a critical hardware optimization that directly impacts security.

In the absence of a direct hardware solution, software-oriented workarounds are being explored. The paper mentions an ongoing Mesa patch (Mesa being a popular open-source graphics driver implementation) that aims to allow the creation of GPU textures with hardware compression disabled. While a step in the right direction, this patch is acknowledged as a workaround with significant limitations. Firstly, there are scenarios where hardware compression cannot be easily disabled by software, even with such a patch. Secondly, disabling compression entirely can have a significant impact on software performance, negating the very reason the compression was introduced. This trade-off between security and performance creates a dilemma for developers and users.

Ultimately, the findings of GPU.zip motivate a broader discussion within the security community and among hardware vendors about the need to formalize and spell out the hardware-software contract with respect to security isolation. As microarchitectural optimizations become increasingly complex and deeply integrated into hardware, their potential side-channel implications must be rigorously evaluated and documented. Future hardware designs should incorporate security primitives that allow software to manage or query the security properties of hardware features, rather than leaving critical security decisions to undocumented, transparent, and unmanageable hardware behavior. This includes considering the information flow characteristics of performance optimizations and providing explicit control mechanisms to prevent unintended information leakage.

Key Takeaways

• Novel Side Channel: GPU.zip introduces a new class of compression side-channel attacks that exploit hardware-based graphical data compression within modern GPUs, distinct from prior software-visible attacks.
• Software Transparency & Vendor Specificity: The core vulnerability stems from the fact that this compression is entirely transparent to software and implemented via undocumented, vendor-specific algorithms, making it impossible for applications to control or anticipate its security implications.
• Observable Microarchitectural Traces: The compressibility of graphical data leaves measurable microarchitectural traces, primarily in memory controller traffic and rendering time, which a collocated attacker can observe to infer data patterns.
• Real-World Exploitability: The research demonstrates an end-to-end pixel-stealing attack that bypasses the browser's Same-Origin Policy by exploiting these timing side channels, allowing an attacker to reconstruct sensitive on-screen content pixel by pixel.
• Missing Hardware-Software Contract: GPU.zip highlights the critical absence of a clear security contract between hardware and software, where performance optimizations in hardware can inadvertently create significant security vulnerabilities.
• Urgent Need for Vendor Action: The most robust mitigation requires GPU vendors to provide software-accessible controls to disable or manage graphical data compression for sensitive data, moving beyond current software-only workarounds that often incur performance penalties.

About the Speaker(s)

The lead speaker for "GPU.zip: On the Side-Channel Implications of Hardware-Based Graphical Data Compression" was Yingchen Wang. He presented this work which was a collaborative effort with Riccardo Paccagnella, Zhao Gang, Willy R. Vasquez, David Kohlbrenner, Hovav Shacham, and Chris. While specific affiliations and titles were not detailed in the provided transcript, the collective expertise of this research team, particularly with prominent names like David Kohlbrenner and Hovav Shacham, suggests a strong background in computer security, microarchitecture, and side-channel analysis. Their contributions highlight a deep understanding of hardware-software interactions and the complex landscape of modern system security.