💻 computer science

ColumnKeeper: Efficient Solutions to the ColumnDisturb Vulnerability in DRAM-based Systems

Dieses Paper stellt ColumnKeeper vor, die erste Gruppe von Minderungsmechanismen (deterministisch CK-D und probabilistisch CK-P), die die neu entdeckte ColumnDisturb-Schwachstelle in DRAM effektiv verhindern, indem sie Spaltenaktivierungen verfolgen oder Zeilen probabilistisch auffrischen, wodurch eine hohe Sicherheit bei minimalen Leistungs-, Energie- und Flächen-Overheads erreicht wird.

Ursprüngliche Autoren: Andreas Kosmas Kakolyris, F. Nisa Bostanci, Ataberk Olgun, Ismail Emir Yuksel, Harsh Songara, Konstantinos Marios Sgouras, Umut Baser, Konstantinos Kanellopoulos, A. Giray Yaglikci, Onut Mutlu

Veröffentlicht 2026-06-23

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Andreas Kosmas Kakolyris, F. Nisa Bostanci, Ataberk Olgun, Ismail Emir Yuksel, Harsh Songara, Konstantinos Marios Sgouras, Umut Baser, Konstantinos Kanellopoulos, A. Giray Yaglikci, Onut Mutlu

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, der Speicher Ihres Computers (DRAM) ist eine riesige, Hochgeschwindigkeits-Bibliothek. Im Inneren dieser Bibliothek befinden sich Millionen winziger Regale (Zeilen), die Bücher (Daten) halten. Seit Jahrzehnten machen sich Computerwissenschaftler Sorgen um ein Problem namens RowHammer. Dies ist wie ein ungezogenes Kind, das immer wieder zwischen zwei bestimmten Regalen hin und her rennt und dabei den Boden so stark erschüttert, dass die Bücher auf den benachbarten Regalen herunterfallen und durcheinandergeraten.

Lange Zeit dachten wir, das sei das Schlimmste, was passieren könnte. Aber dieses Paper stellt ein neues, seltsameres Problem vor: ColumnDisturb.

Das neue Problem: Das Erschüttern der „Spalte“

Anstatt den Boden zwischen zwei Regalen zu erschüttern, stellen Sie sich vor, die Bibliothek hat ein einzigartiges Design, bei dem die Regale in vertikalen Spalten angeordnet sind, die einen gemeinsamen Stützbalken teilen.

ColumnDisturb tritt auf, wenn jemand wiederholt eine spezifische vertikale Spalte von Büchern schlägt. Da die Bibliothek so gebaut ist (unter Verwendung dessen, was das Paper als „Open-Bitline-Architektur“ bezeichnet), bewirkt das Schlagen auf eine Spalte nicht nur, dass die Bücher auf diesem Regal betroffen sind. Es lässt den gesamten Stützbalken vibrieren, was dazu führt, dass Bücher in drei gesamten Abschnitten gleichzeitig herunterfallen.

Das alte Problem (RowHammer): Beeinflusst einige benachbarte Regale.
Das neue Problem (ColumnDisturb): Beeinflusst tausende Regale über drei verschiedene Abschnitte hinweg gleichzeitig.

Bestehende Sicherheitswachleute (Schutzmechanismen) wurden darauf trainiert, auf das „Erschüttern des Bodens“ zu achten. Gegen dieses neue „Vibrieren des Balkens“ sind sie jedoch nutzlos, da sie aus dem falschen Winkel schauen und nicht verstehen, dass ein einziger Schlag drei Abschnitte gleichzeitig beeinflusst.

Die Lösung: ColumnKeeper

Die Autoren schlagen ein neues Sicherheitssystem namens ColumnKeeper vor. Stellen Sie sich dies als ein neues Regelwerk für die Bibliotheks-Wachleute vor, um zu verhindern, dass Bücher herunterfallen. Sie bieten zwei verschiedene Arten von Wachleuten an:

1. Der deterministische Wachmann (ColumnKeeper-D)

Dieser Wachmann ist wie ein präziser Buchhalter.

Wie er funktioniert: Der Wachmann weiß, dass wenn man eine Spalte schlägt, dies die „ungeraden“ Bücher in einem Abschnitt und die „geraden“ Bücher im benachbarten Abschnitt beeinflusst.
Der Trick: Anstatt nur zu zählen: „Wie oft wurde diese Spalte geschlagen?“, führt dieser Wachmann zwei separate Punktekarten: eine für ungerade Treffer und eine für gerade Treffer.
Warum er klug ist: Wenn man die Spalte so schlägt, dass nur die ungeraden Bücher im Nachbarabschnitt betroffen sind, gerät der Wachmann nicht in Verwirrung und denkt nicht, dass beide Abschnitte getroffen wurden. Er vermeht es, die Treffer „doppelt zu zählen“.
Die Aktion: Sobald der Punktestand auf einer der Karten zu hoch wird, wählt der Wachmann ein zufälliges Buch aus den betroffenen Abschnitten aus und stellt es wieder ins Regal (frischt es auf), bevor es herunterfällt. Er tut dies Buch für Buch, langsam, damit er die Arbeit in der Bibliothek nicht unterbricht.

2. Der probabilistische Wachmann (ColumnKeeper-P)

Dieser Wachmann ist wie ein Münzwurf-Glücksspieler.

Wie er funktioniert: Dieser Wachmann führt gar keine Punktekarten. Jedes Mal, wenn eine Spalte geschlagen wird, wirft der Wachmann eine Münze.
Die Aktion: Wenn die Münze auf „Kopf“ fällt (was mit einer sehr spezifischen, berechneten Wahrscheinlichkeit geschieht), geht der Wachmann sofort und frischt ein Buch in den drei betroffenen Abschnitten auf.
Warum er gut ist: Er ist viel einfacher zu bauen (weniger Hardware erforderlich) und kostengünstiger. Obwohl er nicht zu 100 % garantiert, jeden einzelnen Treffer abzufangen, zeigt die Mathematik, dass die Chance, dass ein Buch herunterfällt, so unglaublich gering ist (wie das mehrfache Gewinnen der Lotterie hintereinander), dass es für fast jede Situation sicher genug ist.

Wie gut funktioniert es?

Die Autoren haben ihre Wachleute in einer simulierten Computerumgebung getestet. Hier ist das, was sie herausgefunden haben:

Geschwindigkeit: Die Wachleute sind sehr schnell. In dem aktuellen „sicheren“ Szenario (in dem es 1 Million Treffer braucht, um den Speicher zu beschädigen) verlangsamen die Wachleute den Computer fast gar nicht (weniger als 0,5 %). Selbst in einem „nahen Zukunftsszenario“, in dem der Speicher fragiler ist (128.000 Treffer), ist die Verlangsamung immer noch sehr gering (etwa 1–3 %).
Energie: Die Wachleute verbrauchen nicht viel zusätzliche Elektrizität.
Größe: Die Hardware, die benötigt wird, um diese Wachleute hinzuzufügen, ist winzig. Der „Buchhalter“-Wachmann nimmt etwa 0,1 Quadratmillimeter Platz auf einem Chip ein, und der „Glücksspieler“-Wachmann sogar noch weniger, nämlich 0,03 Quadratmillimeter. Das ist etwa so groß wie ein Sandkorn.

Die „Was wäre wenn“-Szenarien

Das Paper untersuchte auch, was passiert, wenn der Speicher in der Zukunft extrem fragil wird (nur 16.000 Treffer benötigt, um zu brechen).

Das Problem: Die Wachleute müssten die Bücher so oft auffrischen, dass sich die Bibliothek erheblich verlangsamen würde.
Die Lösung: Das Paper schlägt zwei Wege vor, um dies zu beheben:
1. Kleinere Regale: Wenn die Bibliotheksabschnitte (Subarrays) kleiner wären, müssten die Wachleute nicht so viele Bücher prüfen.
2. Parallele Wachleute: Wenn die Bibliothek mehrere Wachleute zulassen würde, die gleichzeitig an verschiedenen Abschnitten arbeiten (eine Funktion namens Subarray-Level-Parallelism), wäre die Verlangsamung viel weniger gravierend.

Zusammenfassung

ColumnKeeper ist das erste System, das speziell entwickelt wurde, um dieses neue „ColumnDisturb“-Vibrationsproblem zu stoppen. Es bietet zwei Optionen:

ColumnKeeper-D: Ein intelligentes, präzises System, das Treffer sorgfältig zählt, um unnötige Arbeit zu vermeiden.
ColumnKeeper-P: Ein einfacheres, günstigeres System, das auf Zufall setzt, um sicher zu bleiben.

Beide Optionen schützen Ihren Computer vor Abstürzen oder dem Durchsickern von Daten, bei minimalem Aufwand für Geschwindigkeit oder Akkulaufzeit, und sie können mit fast keinem zusätzlichen Platzbedarf in zukünftige Computer eingebaut werden.

Technisches Resümee: ColumnKeeper

1. Problemstellung

Moderne DRAM-Chips sind anfällig für Read-Disturbance-Phänomene, insbesondere RowHammer und RowPress, bei denen wiederholte Zugriffe auf „Aggressor“-Reihen Bit-Flips in benachbarten „Victim“-Reihen induzieren. Während bestehende Minderungsstrategien die Aktivierungen von Reihen verfolgen, um potenzielle Opfer zu aktualisieren, macht ein neu entdecktes Phänomen namens ColumnDisturb diese Ansätze unwirksam.

ColumnDisturb unterscheidet sich grundlegend von reihenbasierten Störungen:

Mechanismus: Es wird durch den wiederholten Zugriff auf dieselbe Spalte von DRAM-Zellen induziert, anstatt durch Reihen.
Umfang: Aufgrund der Open-Bitline-Architektur moderner DRAMs, bei der Sense-Amplifier zwischen benachbarten Subarrays in einer verschachtelten Weise geteilt werden, beeinflusst das Hämmern einer einzelnen Spalte alle Zellen, die diese Bitline teilen. Folglich stört eine einzige Reihenaktivierung in einem Subarray Zellen über drei aufeinanderfolgende Subarrays hinweg (das aktivierte Subarray und seine unmittelbaren Nachbarn).
Auswirkung: Dies betrifft tausende Reihen und Millionen von Zellen gleichzeitig. Bestehende RowHammer-Minderungen, die auf Reihenebene operieren und spezifische Aggressor-Reihen verfolgen, können gegen ColumnDisturb nicht schützen, da sie die Blast-Radius auf Subarray-Ebene und die spezifischen Bitline-Sharing-Muster nicht berücksichtigen.
Versagen naiver Minderungsstrategien: Eine einfache Erhöhung der DRAM-Refresh-Rate zur Bekämpfung von ColumnDisturb verursacht schwere Performance- und Energieeinbußen, insbesondere da der ColumnDisturb-Schwellenwert ( $N_{CD}$ ) mit der Technologiefortschritt sinkt. Ebenso führen Modifikationen bestehender Reihen-Tracking-Mechanismen (wie PRAC), die alle Reihen in drei Subarrays bei Überschreiten eines Schwellenwerts aktualisieren, zu übermäßigen unnötigen Refreshes und hohen Overheads.

2. Methodik: ColumnKeeper

Die Autoren schlagen ColumnKeeper vor, den ersten Satz von Mechanismen, die darauf ausgelegt sind, ColumnDisturb-Bit-Flips mit geringem Performance-, Energie- und Flächenoverhead zu mildern. ColumnKeeper operiert auf der Subarray-Granularität und verwendet zwei Varianten: einen deterministischen Mechanismus (ColumnKeeper-D oder CK-D) und einen probabilistischen (ColumnKeeper-P oder CK-P).

Gemeinsame Komponenten

Beide Varianten nutzen eine Row Pointer Table (RPT), um das Ziel der präventiven Refreshes zu verwalten. Die RPT führt einen Eintrag pro Subarray, der auf die nächste zu aktualisierende Reihe zeigt. Wenn ein Refresh ausgelöst wird, aktualisiert der Mechanismus die angezeigte Reihe und erhöht den Pointer in einer Round-Robin-Abfolge. Dies stellt sicher, dass alle Reihen in einem betroffenen Subarray iterativ aktualisiert werden, bevor der ColumnDisturb-Schwellenwert erreicht wird, wodurch die Latenz durch das gleichzeitige Aktualisieren aller Reihen vermieden wird.

ColumnKeeper-D (CK-D): Deterministische Minderung

CK-D ist darauf ausgelegt, deterministische Sicherheitsgarantien zu bieten, indem es Aktivierungen genau verfolgt und gleichzeitig „Double-Counting“ vermeidet.

Das Double-Counting-Problem: In einer Open-Bitline-Architektur beeinflusst eine Reihenaktivierung in einem zentralen Subarray gerade Spalten in einem Nachbarn und ungerade Spalten im anderen. Ein naiver Zähler, der alle Aktivierungen in einem Nachbarn summiert, würde die Hammer-Anzahl für spezifische Bitlines überschätzen und unnötige Refreshes auslösen.
Lösung: CK-D führt zwei separate Counter-Tabellen pro Subarray, Counter Table-Even (CT-E) und Counter Table-Odd (CT-O), .
- Wenn eine Reihe in Subarray $k$ aktiviert wird, erhöht CK-D sowohl CT-E als auch CT-O für Subarray $k$ (da alle Spalten betroffen sind).
- Für die benachbarten Subarrays ( $k-1$ und $k+1$ ) erhöht es nur den spezifischen Counter, der den betroffenen Bitlines entspricht (z. B. CT-E für $k-1$ und CT-O für $k+1$ ).
Trigger: Der Mechanismus berechnet das Maximum der geraden und ungeraden Counter für ein Subarray. Wenn dieser Wert einen Schwellenwert ( $N_{PR} = N_{CD} / S$ , wobei $S$ die Subarray-Größe ist) erreicht, löst er einen präventiven Refresh für dieses Subarray unter Verwendung der RPT aus.
Sicherheit: Die Autoren beweisen mittels Induktion, dass CK-D Bit-Flips unter Worst-Case-Zugriffsmustern deterministisch verhindert.

ColumnKeeper-P (CK-P): Probabilistische Minderung

CK-P zielt darauf ab, die Hardware-Komplexität zu reduzieren, indem es Aktivierungs-Counter vollständig eliminiert.

Mechanismus: Bei jeder Reihenaktivierung in einem Subarray gibt CK-P mit einer vordefinierten Wahrscheinlichkeit ( $P_{PR}$ ) präventive Refreshes an das aktivierte Subarray und seine zwei Nachbarn aus.
Konfiguration: Die Wahrscheinlichkeit $P_{PR}$ wird so berechnet, dass die Wahrscheinlichkeit eines erfolgreichen ColumnDisturb-Angriffs innerhalb eines bestimmten Zeitrahmens (z. B. ein Jahr) unter einer konfigurierbaren Grenze ( $P_Y$ ) bleibt.
Trade-off: Dieser Ansatz bietet einen geringeren Flächenoverhead, liefert jedoch konfigurierbare Sicherheitsgarantien anstelle von deterministischen.

Umgang mit impliziten Aktivierungen

Beide Mechanismen müssen die durch periodische Refreshes (REF) und RowHammer-Präventiv-Refreshes (RFM) verursachten impliziten Aktivierungen berücksichtigen.

Periodische Refreshes: Da REF-Befehle kein Subarray spezifizieren, zieht CK-D konservativ eine Sicherheitsmarge ( $2S$ ) von der Schwellenwertberechnung ab, um die maximale Hammer-Anzahl zu berücksichtigen, die eine Reihe durch globale Refreshes erhält.
Integration der RowHammer-Minderung: In Kombination mit RowHammer-Abwehrmechanismen (wie PRAC) behandelt ColumnKeeper seine eigenen Refreshes als explizite Aktivierungen. Für externe REF/RFM-Befehle, die jedes Subarray betreffen können, erhöht CK-D alle Counter (oder aktualisiert alle Subarrays in CK-P), um die Sicherheit aufrechtzuerhalten.

3. Kernbeiträge

Erste Minderung für ColumnDisturb: Das Paper führt die ersten praktischen Mechanismen (CK-D und CK-P) ein, die speziell darauf ausgelegt sind, ColumnDisturb-Bit-Flips zu mildern.
Architektonische Erkenntnis: Das Design nutzt die Open-Bitline-Architektur, um die Verfolgung von ungeraden und geraden Spalten zu trennen (in CK-D), wodurch die Überschätzung der Aktivierungszahlen vermieden wird, die naive Lösungen belastet.
Sicherheitsanalyse:
- CK-D: Es wurde bewiesen, dass CK-D Bit-Flips gegen Worst-Case-Zugriffsmuster deterministisch verhindert.
- CK-P: Bietet konfigurierbare Sicherheitsgarantien, wobei die Wahrscheinlichkeit eines Fehlers mathematisch begrenzt und mittels Monte-Carlo-Simulationen validiert wurde.
Umfassende Evaluierung: Die Autoren evaluieren die Mechanismen mittels einer zyklusgenauen Simulation (Ramulator 2.0) und einer Leistungsanalyse (DRAMPower) über 62 Single-Core- und 60 Multi-Core-Workloads.

4. Ergebnisse

Die Evaluierung zeigt, dass ColumnKeeper signifikante Sicherheit mit minimalen Overheads bei aktuellen und nahen zukünftigen Schwellenwerten erreicht.

Performance-Overhead:
- Beim aktuellen experimentellen Schwellenwert ( $N_{CD} = 1M$ ) verursachen CK-D und CK-P durchschnittliche Single-Core-Performance-Overheads von 0,15 % bzw. 0,36 %.
- Bei einem „nahezu zukünftigen“ Schwellenwert ( $N_{CD} = 128K$ ) steigen die Overheads auf 1,70 % (CK-D) und 2,73 % (CK-P).
- Bei sehr niedrigen Schwellenwerten ( $N_{CD} = 16K$ ) sind die Overheads signifikant (z. B. ~1,7 % Durchschnitt für CK-D), können aber durch Reduzierung der Subarray-Größen oder Aktivierung von Subarray-Level Parallelism (SALP) gemildert werden.
Energie und Fläche:
- Die Energie-Overheads sind bei aktuellen Schwellenwerten niedrig (<2 % für $N_{CD}=1M$ ), steigen aber an, wenn der Schwellenwert sinkt.
- Die Flächen-Overheads sind minimal: 0,1 mm² für CK-D und 0,03 mm² für CK-P.
Multi-Core-Auswirkungen: Multi-Core-Workloads zeigen etwas höhere Overheads aufgrund erhöhter Row-Buffer-Konflikte, aber der relative Vorteil von CK-D gegenüber CK-P bleibt konsistent.
In-DRAM-Implementierung: Das Paper untersucht eine In-DRAM-Implementierung von CK-D (unter Wiederverwendung von PRAC-Signalen), welche die Overheads bei niedrigen Schwellenwerten erheblich reduziert (z. B. Beibehaltung von >0,97 IPC bei $N_{CD}=16K$ ), indem sie konservative Counter-Erhöhungen für RFM-Befehle vermeidet.

5. Bedeutung und Ansprüche

Das Paper behauptet, dass ColumnKeeper die erste Lösung ist, die in der Lage ist, ColumnDisturb ohne die prohibitiven Performance- und Energiekosten zu verteidigen, die mit naiven Minderungsstrategien (wie der Erhöhung der globalen Refresh-Rate) verbunden sind.

Praktikabilität: Die Mechanismen sind so konzipiert, dass sie mit geringen Flächen- und Stromkosten im Speichercontroller (oder potenziell In-DRAM) implementiert werden können, was sie für eine kurzfristige Einführung attraktiv macht.
Skalierbarkeit: Während aktuelle Schwellenwerte handhabbar sind, räumt das Paper ein, dass zukünftiger Technologiefortschritt $N_{CD}$ senken wird. Die Effektivität von ColumnKeeper bei diesen niedrigeren Schwellenwerten kann durch architektonische Modifikationen (kleinere Subarrays, SALP) oder In-DRAM-Integration erreicht werden.
Open Source: Die Autoren geben an, dass ColumnKeeper der Forschungsgemeinschaft kostenlos zur Verfügung steht, um weitere Studien und Entwicklungen zu erleichtern.

Das Werk kommt zu dem Schluss, dass ColumnDisturb zwar eine fundamentale Herausforderung für die DRAM-Isolation darstellt, aber effektiv durch gezielte architektonische Mechanismen gemildert werden kann, die die physikalischen Realitäten moderner DRAM-Subarrays respektieren.