Side-Channel Attacks on Optane Persistent Memory

# Side-Channel Attacks on Optane Persistent Memory: Technical Deep Dive

*Published: [Today’s Date]*

---

## Table of Contents

- [Introduction: What Are Side-Channel Attacks?](#introduction-what-are-side-channel-attacks)
- [Overview of Intel Optane Persistent Memory](#overview-of-intel-optane-persistent-memory)
- [Why Side-Channel Attacks Matter in Optane PM](#why-side-channel-attacks-matter-in-optane-pm)
- [Understanding the Internal Cache Hierarchy in Optane](#understanding-the-internal-cache-hierarchy-in-optane)
- [Breakdown: Prime+Probe Side-Channel Attack](#breakdown-primeprobe-side-channel-attack)
- [Reverse Engineering Optane’s Cache Behavior](#reverse-engineering-optanes-cache-behavior)
- [Real-World Examples: Side-Channel Attacks in Action](#real-world-examples-side-channel-attacks-in-action)
- [Code Labs: Detecting Side Channels on Optane](#code-labs-detecting-side-channels-on-optane)
- [Mitigation Strategies & Security Best Practices](#mitigation-strategies--security-best-practices)
- [Side Channel Resistance: The Developer’s Checklist](#side-channel-resistance-the-developers-checklist)
- [Conclusion: The Path Forward](#conclusion-the-path-forward)
- [References](#references)

---

## Introduction: What Are Side-Channel Attacks?

A **side-channel attack** is a powerful class of security exploit where an attacker seeks sensitive information—not by breaking the intended cryptographic scheme—but by studying implementation artifacts such as cache access patterns, timing, power, electromagnetic (EM) emissions, or even sound and vibrations.

In short, **side-channels** are the “accidental” leaks in any computation: tiny data trails left by physical or logical components as they process protected information.

**Real-world analogy:**  
Think of a lock-picking scenario. Instead of brute-forcing the key, you listen closely as each pin tumbles into place—sound and timing betray information!

**Common side-channels:**

- **Cache Timing:** Infers data by measuring memory access times (e.g., Prime+Probe, Flush+Reload attacks).
- **Power Analysis:** Monitors power consumption to infer secrets (common in smartcards).
- **Electromagnetic Leaks:** Captures EM signatures of devices during sensitive operations.

**Why they matter:**  
Side-channel attacks can subvert even the most mathematically robust cryptosystems, often requiring no software vulnerabilities—merely proximity or access to shared computing resources.

---

## Overview of Intel Optane Persistent Memory

**Intel Optane Persistent Memory (PMem)** belongs to a new class of memory called **non-volatile memory (NVM)**. Unlike traditional DRAM, which loses its contents upon power-off, Optane retains data—blurring the boundary between RAM and storage.

**Key Features:**

- **Persistence:** Maintains data even after power loss.
- **Byte-addressability:** Allows random, low-latency access much like RAM.
- **High Capacity:** Scales up to terabytes per module.

### Where Optane PM is Used:

- High-availability databases
- In-memory analytics
- Accelerated storage caches

**A typical Optane system:**
```plaintext
[CPU] <---> [L1/L2/L3 CPU Caches] <---> [Memory Controller] <---> [Optane Persistent Memory (PMem)]
                                                   ^
        [Traditional DRAM] ------------------------/

Why Side-Channel Attacks Matter in Optane PM

The persistence, high density, and close integration of Optane PM with CPU caches make it an exciting yet complex target for side-channel attackers.
Until recently, most side-channel research focused on DRAM or CPU caches, but Optane’s distinct hardware and new internal cache structure introduce novel attack vectors.

What’s New?

• Persistent state: Attackers can probe data that survives reboots or crashes.
• Shared multi-tenant environments: Cloud and virtualization increase the risk attackers can co-locate and exploit shared hardware.
• Unique caching: Optane has its own on-die caches distinct from DRAM or CPU-side caches.

Key Research Breakthrough

The paper "Persistent State Side-channel Attacks on Intel Optane Persistent Memory" presents the first systematic side-channel security analysis of Optane—revealing that previously secure assumptions no longer hold, and motivates new defensive strategies.

Understanding the Internal Cache Hierarchy in Optane

Traditional memory architectures have a well-documented cache hierarchy: L1, L2, L3 on the CPU, and possibly row and bank buffers in DRAM. Optane PM, on the other hand, exhibits internal, undocumented caches.

Reverse-Engineered Optane Cache Hierarchy

The USENIX 2023 study employed microbenchmarking to unveil Optane's buffer architecture. The internal cache hierarchy is roughly as follows:

• On-Die Buffers (in Optane PM): Optane implements large last-level "line buffers" that span hundreds of kilobytes, much larger than typical DRAM row buffers.
• Memory Controller Buffers: Additional caching closer to the CPU.
• CPU-side Caches (L1/L2/L3): Traditional, but crucial in side-channel setups.

How Optane Caching Differs from DRAM

The size and persistence of Optane line buffers enable new, high-resolution temporal and spatial side channels.

Breakdown: Prime+Probe Side-Channel Attack

What is Prime+Probe?

Prime+Probe is a cache timing attack commonly used to infer access patterns in shared-memory environments.

How it works, in three steps:

1. Prime: The attacker fills (primes) a cache or buffer with their data.
2. Wait: The victim executes, possibly evicting some of the attacker's data by loading sensitive data into the same cache lines/buffers.
3. Probe: The attacker measures access times when re-accessing their data—slow means evicted, fast means still present.

Prime+Probe on Optane

Because Optane’s internal line buffers are large and persistent, Prime+Probe gains powerful new capabilities:

• Attacker and victim don’t have to run simultaneously.
• Line buffer can survive reboots, so cross-session attacks are possible.
• Large buffer sizes mean attackers can monitor much broader regions of memory at once.

Practical Implication:
Malware or tenant A could probe Optane’s buffer occupancy, learning which memory regions tenant B is accessing—even after a crash or reboot.

Reverse Engineering Optane’s Cache Behavior

A crucial step in evaluating security is understanding the hardware. The research paper used timing microbenchmarks to empirically uncover:

• Buffer sizes and structure
• Eviction replacement policy
• Mapping from physical address to buffer lines

Microbenchmarking: The Tools of the Trade

Researchers crafted low-level tools to rapidly access (read/write) sequences of memory addresses and record the timings. Variations in timing indicate cache/buffer hits and misses.

Example: Measuring Access Latency

import time
import mmap

ADDR = 0x10000000  # Example physical address mapped

with open("/dev/mem", "rb") as f:
    mem = mmap.mmap(f.fileno(), 4096, offset=ADDR)
    t1 = time.perf_counter_ns()
    data = mem.read(64)
    t2 = time.perf_counter_ns()
    latency = t2 - t1
    print(f"Read latency: {latency} ns")
    mem.close()

Note: Accessing /dev/mem and physical addresses requires root! Use in a controlled lab environment.

Finding Reuse Distance

By varying strides and measuring latencies, researchers mapped how many addresses co-reside in a buffer before eviction happens—thus reverse-engineering the cache’s associativity.

Real-World Examples: Side-Channel Attacks in Action

Example 1: Attack on a Multi-Tenant Database

Suppose two tenants share hardware in a cloud environment, each using Optane-backed memory. Tenant A launches a Prime+Probe attack on Optane’s line buffers:

1. Tenant A allocates a large persistent memory region, “priming” the line buffers.
2. During a context switch or after a power cycle, tenant B accesses sensitive database records mapped to nearby regions.
3. Tenant A probes previously ‘primed’ regions, measuring changes in access latency to detect evictions, and hence infers what data tenant B accessed.

Practical Outcome:

• Even encrypted databases leak access patterns.
• Information about frequently accessed (“hot”) records may be inferred.
• Attack is robust across reboots or VM migrations!

Example 2: Exploiting Buffer Persistence Post-Reboot

Suppose Optane’s buffer isn’t cleared after power loss (or resumes quickly enough for buffers to persist):

• Attacker “primes” before forced power-off (e.g., scheduled maintenance).
• After reboot, the attacker probes again—timing differences can reflect what the legitimate user accessed during initial boot/application startup.

Code Labs: Detecting Side Channels on Optane

For researchers and red-teamers, running your own microbenchmarks is instructive. Below are basic code samples for scanning Optane buffers and parsing timing data in Bash and Python.

Bash: Basic Timing Microbenchmark

#!/bin/bash
# Measure mmap'd memory read times
FILE="/mnt/pmem0/testfile"
dd if=/dev/zero of=$FILE bs=64K count=1  # Prepare file

for i in {1..1000}; do
  t1=$(date +%s%N)
  dd if=$FILE of=/dev/null bs=64 count=1 iflag=direct 2>/dev/null
  t2=$(date +%s%N)
  echo "$(($t2 - $t1))"
done > timings.txt

Parsing and Plotting in Python

import matplotlib.pyplot as plt

with open("timings.txt") as f:
    times = [int(line.strip()) for line in f]

plt.plot(times)
plt.xlabel("Iteration")
plt.ylabel("Time (ns)")
plt.title("Optane Access Latency Microbenchmark")
plt.show()

What to look for:
Repeating patterns—a “spike” in access time usually indicates a buffer miss (eviction by another process).

Advanced: Profiling Access Patterns

More advanced tools would allocate a large array mapped directly to Optane PM and access it in patterns calculated to target specific line buffers—then use timing data to reconstruct the mapping.

Caution:
While useful for research, these actions may violate provider policy on production hardware. Limit to air-gapped, dedicated test environments.

Mitigation Strategies & Security Best Practices

Side-channel resistance is multi-faceted, involving hardware, system software, and application-level mitigations.

Hardware Mitigations

• Partitioned Line Buffers: Isolate tenant or process data at the hardware level.
• Randomized Mapping: Randomize the mapping from addresses to buffers to limit attack predictability.
• Buffer Zeroization: Proactively clear line buffers, especially upon reset.

System & OS Mitigations

• Process/VM Scheduling: Avoid co-locating sensitive tenants on the same hardware.
• Flush after Context Switch: Forcefully evict buffer contents when switching between security domains.
• Access Pattern Obfuscation: Introduce random delays or dummy accesses to confuse timing-based attacks.

Coding Defenses for Developers

Implement cryptographic routines and sensitive data accesses in a constant-time and constant-pattern manner:

• Avoid data-dependent branching/loops.
• Use memory access patterns that don’t vary with secret data.

Side Channel Resistance: The Developer’s Checklist

1. Assess hardware side-channels: Understand and enumerate all physical buffers (CPU, memory, SSD/PMem).
2. Analyze security domains: Are multiple users/tenants sharing hardware concurrently or sequentially?
3. Enforce access control: Use hardware or hypervisor support to strictly limit cross-tenant buffer sharing.
4. Employ constant-time programming: All sensitive computations (crypto, authentication) must avoid timing leaks.
5. Deploy noise injection where feasible: Add timing jitter or dummy memory accesses, keeping usability in mind.
6. Keep firmware/microcode updated: Accept vendor patches that harden buffer management.

Tools and Resources:

• Intel’s Security Best Practices for Side Channel Resistance
• Open-source side-channel analysis tools (search for “cache side-channel tools”)

Conclusion: The Path Forward

As persistent memory technologies like Intel Optane PM scale across data centers, cloud, and AI infrastructure, the side-channel attack surface evolves. The internal buffer architecture—once ignored as a threat vector—now warrants systematic attention from both industry and research.

Key Takeaways:

• Side-channels are a fundamental challenge, not “side” issues, in security.
• Optane PM introduces new, persistent avenues for side-channel exploitation.
• Security best practices must adapt—from cache management to constant-time code.
• Users of cloud, virtualization, or multi-user servers must ask: Do my hardware and hypervisor protect me from buffer-based side channels?

Stay Informed:
Regularly review hardware advisories, security research, and deploy mitigations proactively to keep ahead of attackers exploiting emergent technology side-channels.

References

1. Liu, Sihang et al. Persistent State Side-channel Attacks on Intel Optane Persistent Memory, USENIX Security Symposium 2023
2. "Side Channel — An Overview", Elsevier ScienceDirect, Link
3. Intel, "Software Security Guidance: Security Best Practices for Side Channel Resistance", Link
4. Intel Optane Persistent Memory Documentation, Link
5. A Survey of Microarchitectural Side-channel Vulnerabilities, Attacks, and Defenses in Cryptography

This post is part of a series on hardware security and emerging memory technologies. If you found it insightful, share with your team and subscribe for updates on next-generation cybersecurity.

*Note: Always experiment with side-channel attacks in dedicated, legal, and permissioned environments.*