## Pseudo-code Diagram: Spectre v1 Attack Implementation ### Overview The image displays a structured table containing pseudo-code that outlines the steps for a Spectre v1 (variant 1) speculative execution attack. The code is divided into two main sections: a "Sender" process that performs the malicious speculative access, and a "Receiver" process that extracts the secret data via a timing side-channel. The table has two columns: "Pseudo-code" and "Critical Steps," which map code lines to high-level attack phases. ### Table of Pseudo-code and Critical Steps | Line | Pseudo-code | Critical Step | Notes | |------|-------------|---------------|-------| | 1 | `flushArray(SHAREDPTR, 256);` | Setup | | | 2 | `flush(&array_size);` | Setup | | | 3 | `mistrainPredictor();` | Setup | | | 4 | `ld r5, 0(&array_size)` | (long-latency) Authorize | | | 5 | `bge r3, r5, outside --> if (x < array_size) {` | (long-latency) Authorize | | | 6 | `add r6, r3, r4` | Access | y = arrayPtr[x]; | | 7 | `lbu r7, 0(r6)` | Use | | | 8 | `slli r7, r7, 12` | Use | | | 9 | `add r8, r2, r7` | Use | z = SHAREDPTR[y*4096] | | 10 | `ld r9, 0(r8)` | Send | | | - | `}` | | Closing brace for if statement | | - | `outside:` | | Label for branch target | | 11 | `for i from 0 to 255` | Receive | | | 12 | `t[i] = TimeToReload(SHAREDPTR[i*4096]);` | Receive | | | 13 | `Find the minimal t[i]` | Receive | | ### Key Observations 1. **Attack Flow:** The code clearly separates the attack into three phases: **Setup** (flushing caches and mistraining the branch predictor), **Sender** (executing the speculative gadget with an out-of-bounds `x`), and **Receiver** (probing the cache to detect which `SHAREDPTR` entry was accessed speculatively). 2. **Speculative Gadget:** Lines 6-10 form the core gadget. The branch at line 5 is mistrained to speculatively execute the subsequent instructions even when `x >= array_size`. The red annotations translate the assembly into a C-like expression, showing how an out-of-bounds read (`arrayPtr[x]`) is used to compute a dependent address (`SHAREDPTR[y*4096]`) for a cache side-channel. 3. **Timing Side-Channel:** The Receiver (lines 11-13) uses `TimeToReload` to measure access latency to each page (stride of 4096 bytes) in the `SHAREDPTR` array. The index `i` with the minimal reload time `t[i]` corresponds to the secret value `y` leaked by the Sender. 4. **Critical Steps Mapping:** The right column provides a useful abstraction of the attack's logical phases, linking low-level operations to their purpose in the exploit chain (e.g., "Authorize" for the bounds check, "Send" for the dependent load that leaks data). ### Interpretation This pseudo-code is a canonical representation of the Spectre v1 (bounds check bypass) vulnerability. It demonstrates how a CPU's speculative execution can be manipulated to violate security boundaries. * **What it demonstrates:** The code shows that by mistraining a branch predictor, an attacker can cause the CPU to speculatively execute instructions that access memory outside an intended bounds check (`x < array_size`). This speculative access leaves microarchitectural side-effects (cache state changes) that persist even after the instructions are architecturally rolled back. * **Relationship between elements:** The **Setup** phase prepares the microarchitectural state. The **Sender** creates the speculative window and performs the illicit access, using the secret-dependent address to probe a shared array. The **Receiver** then empirically measures the cache state to decode the secret. The "Critical Steps" column abstracts this into a clear protocol: Setup -> Authorize (bypass) -> Access (secret) -> Use (compute address) -> Send (leak to cache) -> Receive (decode). * **Notable Anomalies/Outliers:** The key "anomaly" is the intentional violation of the branch condition at line 5. The code is designed to make the CPU incorrectly predict that the branch will be taken, leading to the speculative execution of the sensitive gadget (lines 6-10). The `flush` instructions are critical to ensure the side-channel is based on cache hits/misses rather than stale data. * **Significance:** This diagram is a foundational technical document for understanding microarchitectural side-channel attacks. It bridges the gap between abstract vulnerability concepts and concrete implementation, showing precisely how software can exploit hardware optimizations to leak secrets. The clear separation of phases and annotated logic makes it an effective tool for both attack analysis and defense development (e.g., designing constant-time code or hardware mitigations like retpolines).