Rowhammer атака на память: от физики DRAM до root-shell через GPU — полная карта угроз 2026

В апреле 2026 года три группы одновременно представили на IEEE S&P рабочие эксплойты: Rowhammer-атака через GDDR6-память видеокарты NVIDIA даёт полноценный root-shell на хосте. Атака GPUBreach обходит IOMMU - тот самый механизм, который все считали последним рубежом аппаратной изоляции. За 12 лет переворот битов DRAM перестал быть академическим курьёзом: сейчас он затрагивает DDR3, DDR4, DDR5 и GDDR6, а вектор атаки тянется от утечки RSA-ключей до деградации ML-моделей без доступа к промпту. Триллионная инфраструктура AI-вычислений работает на памяти с известным физическим дефектом - и пока что нас спасает только порог входа для атакующего.

Карта темы​

Физика bit flip: как устроена Rowhammer уязвимость DRAM​

Rowhammer - не программная ошибка. Это физическое свойство архитектуры динамической оперативной памяти, и чтобы с ним работать - нужно понимать, что происходит на уровне конденсатора.

Каждый бит в DRAM хранится как заряд крошечного конденсатора, связанного с транзистором доступа. Ячейки формируют двумерный массив: строки (rows) и столбцы (columns), объединённые в банки (banks). Операция чтения активирует целую строку - заряд всех конденсаторов передаётся на sense amplifier. И тут начинается самое интересное: активация строки генерирует электрические помехи для соседей через паразитное ёмкостное взаимодействие (capacitive coupling). При нормальной работе потеря заряда соседних ячеек мизерная - периодический refresh (64 мс для DDR4, 32 мс для DDR5) восстанавливает состояние. Но если одну строку долбить десятки тысяч раз за один refresh-интервал, соседние ячейки теряют достаточно заряда для инверсии логического значения. Это и есть bit flip - переворот бита в DRAM без прямого обращения к затронутой ячейке.

С уменьшением техпроцесса плотность ячеек растёт, расстояние между строками сокращается, паразитная ёмкость увеличивается. Каждое новое поколение DRAM становится более уязвимым к Rowhammer. Не менее. Это не ошибка конкретного производителя - это свойство технологии.

Для практического воспроизведения атаки первый critical path - точное знание маппинга адресов. Физический адрес транслируется контроллером памяти в конкретный bank, row и column. Без этого маппинга невозможно определить, какие виртуальные адреса соответствуют физически соседним строкам. На CPU-системах маппинг восстанавливается через тайминговый анализ: обращения к адресам в одном банке конкурируют за row buffer, что создаёт измеримую разницу во времени доступа. Инструкция rdtscp и hardware performance counters позволяют фиксировать эту разницу с точностью до наносекунд на bare-metal системах (в виртуализированных средах точность TSC деградирует из-за VM-exit trapping и TSC scaling, а доступ к PMU требует perf_event_paranoid ≤ 0). Доступ к /proc/self/pagemap даёт виртуально-физическую трансляцию без привилегий, превращая атаку на память в локально воспроизводимый exploit (удалённая эксплуатация Rowhammer через сеть не описана ни в одном из цитируемых исследований).

Замечание о CVE: Rowhammer как физический класс атак не имеет единого присвоенного CVE. Иногда упоминаемый CVE-2019-0174 описывает лишь побочный канал - частичное раскрытие информации о физических адресах через логическое условие в конкретных микропроцессорах Intel (семейство i9-9900x/9920x/9960x); CVSS в NVD не проставлен, в RHSA оценивается как 3.8 (CWE-205). CVE-2019-0174 не связан с механизмом bit-flip - это самостоятельная уязвимость side-channel утечки адресов. Реальный ущерб от Rowhammer - произвольная модификация page table entries, криптографических ключей и исполняемого кода - выходит далеко за рамки этого CVE.

Эволюция Rowhammer: от DDR3 к DDR5 и обход TRR через Blacksmith​

Первая публичная демонстрация Rowhammer (Kim et al., Carnegie Mellon, 2014) была на DDR3. Атакующий выполнял double-sided hammering - попеременно обращался к строкам выше и ниже целевой, создавая максимальные помехи с обеих сторон. Для DDR3 без mitigation тысячи bit flip возникали за секунды.

Производители памяти отреагировали введением Target Row Refresh (TRR). Механизм отслеживает подозрительно частые активации строк и принудительно обновляет соседние ряды. TRR стал обязательной частью спецификации DDR4 и DDR5, но каждый вендор - Samsung, SK hynix, Micron - реализует его по-своему: разные счётчики, пороговые значения, алгоритмы выбора строк для refresh. Закрытая природа TRR стала его ахиллесовой пятой. Security through obscurity - и вот к чему это приводит.

В 2020 году TRRespass (ETH Zurich / VU Amsterdam) автоматически подбирал паттерны обращений, обходящие конкретную реализацию TRR. Принцип простой: если TRR отслеживает N строк-агрессоров одновременно - используй N+1 агрессора, чтобы хотя бы одна строка осталась неконтролируемой.

Blacksmith (ETH Zurich, 2021) пошёл дальше - фаззинг паттернов доступа. Генератор создавал случайные последовательности обращений к множеству строк, проверял наличие bit flip через mmap + прямое сканирование и эволюционно оптимизировал рабочие паттерны. Результат по заявлениям авторов: bit flip на всех 40 протестированных модулях DDR4.

DDR5 считался защищённым благодаря удвоенной частоте refresh и улучшенному TRR. Исследователи ETH Zurich доказали обратное атакой Phoenix: реверс-инжиниринг TRR-реализации DDR5 выявил «окно возможностей» - после 128 отслеживаемых обращений система защиты открывала промежуток из 64 неконтролируемых активаций. Второй обнаруженный паттерн требовал 2608 маскировочных обращений перед hammer-фазой [параметры по первичной публикации ETH Zurich, требуют независимой верификации]. По заявлениям авторов, Phoenix сработал на всех 15 протестированных модулях DDR5 SK hynix (2021-2024 годов выпуска, 16-64 ГБ). На системе с AMD Ryzen 7 7700X (Zen 4) под Ubuntu 20.04 были продемонстрированы три сценария: модификация PTE, похищение приватного ключа RSA-2048 и эскалация привилегий через sudo.

Практический takeaway: простой double-sided hammering на современных модулях бесполезен - TRR его отсечёт. Начинайте с Blacksmith для автоматического фаззинга паттернов обхода. И обязательно документируйте серийный номер модуля и версию firmware контроллера - результаты кардинально зависят от конкретного экземпляра.

Подробный разбор техник обхода TRR и применения Blacksmith: Rowhammer атака DRAM: эволюция от оригинала до Blacksmith и обход TRR

GPUHammer и GPUBreach: Rowhammer атака на GPU с эскалацией до root​

До 2025 года GPU-память считалась отдельным доменом. GDDR-серия имеет другую физическую организацию, другой контроллер, другие паттерны обновления. GPUHammer (University of Toronto, USENIX Security 2025) разрушил это предположение, продемонстрировав первые Rowhammer bit flip на GDDR6: заявленные 1171 переворот на RTX 3060 и 202 на RTX A6000 [числа по первичной публикации авторов, требуют верификации].

GPUHammer решал три специфичных для GPU проблемы: проприетарный row mapping GDDR6, высокая латентность GPU DRAM и быстрый refresh. Исследователи провели реверс-инжиниринг маппинга строк через тайминговый анализ обращений из CUDA-ядер и оптимизировали hammering-паттерны под GPU-архитектуру. Результат - нецелевая порча данных: снижение точности ML-моделей до 80% (по заявлениям авторов).

Апрель 2026 - точка перелома. Три независимые группы одновременно представили на IEEE S&P полноценные эксплойты:

GPUBreach (University of Toronto) - четырёхэтапная kill chain. Исследователи пропатчили open-source NVIDIA driver и обнаружили, что GPU page tables хранятся в contiguous 2 MB-регионах в GDDR6. Первый регион далеко от пользовательских данных, но при переполнении новый регион аллоцируется из общего пула - рядом с данными атакующего. Через Unified Virtual Memory (UVM) атакующий принудительно создаёт 64 КБ и 4 КБ страницы вместо стандартных 2 МБ, заполняя PT-регионы PTE. Timing side-channel на UVM-аллокациях с вытеснением позволяет детектировать создание новых PT-регионов и позиционировать их в нужных DRAM-строках. Hammering соседних строк вызывает bit flip в PTE - и вот у атакующего произвольный доступ к GPU-памяти. Дальше - коррупция доверенных буферов драйвера, эксплуатация memory-safety багов в NVIDIA kernel driver (ring-0) и root shell. GPUBreach работает при включённом IOMMU.

GDDRHammer (UNC Chapel Hill / Georgia Tech / MBZUAI) [требует верификации] - использует bit flip в апертурных битах PTE, перенаправляя GPU виртуальные адреса на CPU физическую память через PCIe BAR1. Заявлены произвольные DMA-операции, root shell.

GeForge (Purdue / Clemson / U Rochester / U Western Australia) [требует верификации] - таргетирует page directory (PD0), формируя новые маппинги. Требует отключённого IOMMU.

Профиль устойчивости [все данные по заявлениям исследователей, ни одно из исследований не подтверждено в NVD/MITRE]: RTX A6000 (Ampere, GDDR6) - заявлена полная эксплуатация. На RTX 3080 (GDDR6X), RTX 4060/4060 Ti (Ada Lovelace), RTX 5050 (Blackwell, GDDR7) - zero bit flip. Ускорители с HBM (A100, H100, H200) предположительно устойчивы благодаря on-die ECC. По данным Cloud Security Alliance, наибольший профиль риска предположительно несут GPU поколения Ampere с GDDR6, особенно в мультитенантных deployments через NVIDIA MPS.

NVIDIA не выпустила новый security bulletin и не назначила CVE на driver-уязвимости из GPUBreach, перенаправляя на июльский security notice 2025 года, где Rowhammer характеризуется как «общеотраслевая аппаратная проблема». Удобная позиция - мол, это физика, мы тут ни при чём. Но memory-safety баги в kernel driver, которые превращают bit flip в root shell, - это уже не физика. Это код.

Полный разбор kill chain GPUBreach: GPUBreach: Rowhammer атака GPU с эскалацией привилегий до root - полный разбор kill chain

4 вектора эксплуатации Rowhammer: от PTE-tampering до деградации ML-моделей​

Bit flip - это примитив. Между переворотом одного бита и рабочим эксплойтом лежит цепочка действий: какой бит, в каких данных, как до него добраться.

Page Table Entry tampering​

Наиболее мощный вектор, соответствующий MITRE ATT&CK T1068 - Exploitation for Privilege Escalation. Для сценариев модификации бинарных данных (sudo, PTE) иногда по аналогии упоминают T1601 - Modify System Image, но эта техника описывает манипуляции с образами ОС/прошивками (тактика defense-impairment), а не runtime memory corruption - точного соответствия в ATT&CK для bit-flip модификации бинарников в RAM нет. Атакующий добивается bit flip в page frame number (PFN) записи таблицы страниц. Если повреждённый PFN указывает на страницу, содержащую другую таблицу страниц - атакующий может редактировать собственные виртуально-физические маппинги. Фактически произвольный доступ ко всей оперативной памяти. На CPU-системах заполнение памяти PTE выполняется через массовый mmap одной физической страницы на множество виртуальных адресов. На GPU это не работает - GPUBreach использовал UVM-аллокации с принудительным выбором размера страниц.

Кража криптографических ключей​

Phoenix на DDR5 извлекал приватный ключ RSA-2048 через PTE-tampering с последующим чтением памяти целевого процесса (формального T-кода для извлечения ключа через физическую атаку на память в ATT&CK нет; ближайшие аналоги - T1552 - Unsecured Credentials и T1005 - Data from Local System). RAMBleed шёл другим путём: вместо модификации данных жертвы атакующий наблюдал, какие его собственные биты переворачиваются в зависимости от значений в соседних ячейках. (CVE-2019-0174 не связан с механизмом bit-flip - это самостоятельная уязвимость side-channel утечки адресов на конкретных Intel CPU семейства i9-9900x/9920x/9960x.) Техника Frame Feng Shui через Linux buddy allocator размещала страницы жертвы в предсказуемых физических позициях.

Эскалация через sudo​

Phoenix продемонстрировал модификацию бинарных данных sudo для получения root. Время атаки - от минут до часа, в зависимости от конкретного модуля DDR5 и паттерна hammering.

Деградация ML-моделей​

GPUHammer показал снижение точности ML-модели с 80% до случайного угадывания через нецелевые bit flip в весах. GPUBreach расширил вектор: через PTE-tampering стало возможным модифицировать не веса, а GPU assembly code модели. Это значительно труднее обнаружить проверкой контрольных сумм - веса на месте, хеши совпадают, а модель уже не та.


Подробнее о деградации ML-моделей: Bit-Flip атаки на веса LLM: как Rowhammer меняет решения модели без доступа к промпту

Cross-VM Rowhammer: bit flip ломает изоляцию арендаторов в облаке​

Виртуализация от Rowhammer не спасает. Гипервизор изолирует виртуальные адресные пространства, но физическая DRAM остаётся общей. Если VM атакующего и VM жертвы сидят на одном DIMM-модуле - строки-агрессоры в памяти атакующего могут вызвать bit flip в строках жертвы. Гипервизор об этом не узнает: переворот происходит на аппаратном уровне, ниже любого программного контроля.

Практическая атака cross-VM Rowhammer требует решения двух задач. Первая - определить физическую топологию: находятся ли страницы атакующего и жертвы в одном банке DRAM, в соседних строках. На облачных платформах hugepages и transparent huge pages упрощают задачу - 2 МБ-страницы с большей вероятностью занимают последовательные физические строки. Вторая задача - race condition с refresh: hammering должен создать достаточное количество активаций между refresh-циклами, несмотря на шум от работы других VM на том же хосте.

Для облачных провайдеров cross-VM Rowhammer - системный риск. Изоляция арендаторов строится на программных границах: MMU, IOMMU, гипервизор. Rowhammer обходит все три, работая на уровне электрических помех между конденсаторами. Единственная аппаратная защита - ECC-память, стандартная для серверов, но, как показали исследования, неполная при многобитных flips.

Бизнес-логика атаки: противник арендует GPU-инстанс или VM у того же провайдера, что и жертва. Через timing side-channel определяет co-location. Запускает hammering, целясь в PTE жертвы. В мультитенантном GPU-окружении (NVIDIA MPS) все CUDA-контексты делят GDDR6 - co-location гарантирована. Не нужно даже угадывать.

Подробный разбор: Cross-VM Rowhammer атака: как переворот битов в DRAM ломает изоляцию арендаторов в облаке

Cold Boot и DMA-атаки: извлечение ключей из оперативной памяти​

Rowhammer - не единственный аппаратный вектор против оперативной памяти. Cold Boot Attack и DMA-атаки работают в другой threat model, но бьют по тому же объекту: данные в DRAM.

Cold Boot Attack эксплуатирует физическое свойство DRAM: конденсаторы сохраняют заряд секунды после отключения питания. При охлаждении модуля (аэрозольный хладагент, жидкий азот) время удержания заряда возрастает до минут. Атакующий с физическим доступом отключает питание, замораживает DIMM, переставляет модуль в контролируемую систему и снимает дамп. Ключи полнодискового шифрования (BitLocker, LUKS), хранящиеся в RAM, извлекаются из дампа. Mitigation - secure memory overwrite при shutdown и suspend - работает, только если ОС успевает выполнить очистку. А если выдернуть питание - не успевает.

DMA-атаки используют прямой доступ к физической памяти через шины PCIe, Thunderbolt, FireWire. Вредоносное устройство, подключённое к порту, отправляет DMA-запросы к произвольным физическим адресам, читая и записывая содержимое RAM без участия CPU. IOMMU (VT-d, AMD-Vi) призван ограничить DMA-доступ, но не все системы активируют его по умолчанию, а GPUBreach продемонстрировал обход даже включённого IOMMU через уязвимости драйвера.

Связь с Rowhammer: все три вектора - Rowhammer, Cold Boot, DMA - атакуют данные на уровне физической памяти, ниже программных абстракций. Защита от одного не защищает от другого. Организации, строящие модель угроз для критической инфраструктуры (ФЗ-187, приказ ФСТЭК 239), должны учитывать все три вектора как часть единой категории аппаратных атак на память.

Подробный разбор: Cold Boot Attack и DMA-атаки: извлечение ключей шифрования из оперативной памяти

RowPress, JENGA-эффект и side-channel: новые классы аппаратных атак на память​

Rowhammer - не единственный механизм memory disturbance. Новые классы атак расширяют поверхность угроз, и некоторые из них куда коварнее оригинала.

RowPress - атака, при которой строка DRAM не активируется многократно (как в классическом hammering), а удерживается открытой продолжительное время. Длительное удержание row buffer в активном состоянии создаёт аналогичные электрические помехи для соседних строк и вызывает bit flip. Главная опасность RowPress в том, что он не генерирует аномально высокого числа активаций - того самого паттерна, на который ориентированы TRR и большинство детекторов. Для систем обнаружения, построенных на подсчёте row activations, RowPress практически невидим.

JENGA-эффект - головная боль систем реального времени и safety-critical embedded. В таких системах корректность зависит от гарантий Worst-Case Execution Time (WCET) - максимального времени выполнения задачи. Rowhammer-mitigation (TRR, увеличенный refresh) вносит непредсказуемые задержки в работу контроллера памяти: дополнительные refresh-циклы удлиняют время доступа к данным. Для системы с жёсткими WCET-гарантиями (авионика, промышленные контроллеры, automotive) включение защиты от Rowhammer может нарушить временные гарантии приложения. Дилемма: оставить систему уязвимой к bit flip или сломать WCET. Оба варианта неприемлемы, а третьего пока нет.

Side-channel атаки на генераторы случайных чисел используют совершенно другой физический вектор. Статический side-channel анализ через заморозку тактового генератора или электромагнитные наводки позволяет восстановить внутреннее состояние TRNG/PRNG. В комбинации с Rowhammer (который может повредить seed генератора в памяти) получается составной вектор: ослабление энтропии + предсказуемые ключи.

Общий знаменатель: современные аппаратные атаки на память вышли за пределы классического «забить строку активациями». RowPress, timing side-channel через UVM-аллокации (GPUBreach), статические side-channel на генераторах - все они эксплуатируют физические свойства железа, недоступные программному наблюдению.

Подробный разбор JENGA-эффекта: RowHammer атака на DRAM: JENGA-эффект и крах WCET

Подробнее о side-channel атаках: Static side-channel атака: заморозка генератора

Обнаружение Rowhammer: perf counters, PEBS и uncore-счётчики на практике​

Обнаружить Rowhammer атаку на память тяжело: переворот бита происходит на аппаратном уровне, без участия CPU. Но hammering - многократная активация строки - создаёт побочные эффекты, измеримые через hardware performance counters.

На CPU-платформах Intel и AMD основной индикатор - аномально высокое число cache miss в Last Level Cache (LLC). Hammering требует обхода кеша: каждое обращение к строке-агрессору должно пройти до DRAM, иначе bit flip не возникнет. Атакующий использует clflush/clflushopt для вытеснения строк из кеша или обращается к некешируемым регионам через mmap с MAP_POPULATE. Мониторинг через perf stat -e cache-misses,LLC-load-misses фиксирует аномальные всплески LLC-промахов - тысячи в секунду при нормальном уровне в десятки.

PEBS (Precise Event-Based Sampling) добавляет точность: вместо агрегированных счётчиков PEBS записывает точный адрес инструкции, вызвавшей событие. Можно не просто зафиксировать аномалию, но атрибутировать её конкретному процессу и участку кода.

Uncore-счётчики контроллера памяти (Intel IMC - Integrated Memory Controller) дают прямую видимость row activation count на уровне банка и ранга DRAM. Порог срабатывания: если один банк получает на порядок больше активаций, чем остальные, за один refresh-интервал - это индикатор hammering. Доступ к uncore-счётчикам требует привилегий (root или perf_event_paranoid ≤ 0), что ограничивает применение в shared-окружениях.

Где детектирование не работает: RowPress-атака не генерирует аномального числа активаций и не детектируется через row activation counters. GPU-hammering через CUDA-ядра невидим для CPU performance counters. Для GPU-вектора на момент написания нет опубликованных detection-механизмов за пределами академических прототипов.

Практический чеклист для SOC:

• Мониторинг LLC-miss через perf stat или eBPF-программы
• Алерты на аномальные всплески row activations в uncore-счётчиках IMC
• Для GPU-инфраструктуры: ограничение co-residency через NVIDIA MIG вместо MPS

Подробный гайд: Обнаружение Rowhammer атак через perf counters, PEBS и uncore-счётчики

Защита от Rowhammer: TRR, ECC и PARA - что останавливает атаку в 2026​

Ни один существующий механизм не закрывает Rowhammer полностью. Каждый уровень mitigation сужает окно атаки, но не устраняет его.

Target Row Refresh (TRR) - основная встроенная защита в DDR4/DDR5. Контроллер памяти отслеживает подозрительно частые активации и принудительно обновляет соседние строки. Проблема: TRR - проприетарный механизм, реализация закрыта, и исследователи раз за разом находят паттерны обхода (Blacksmith, Phoenix). По данным исследования Phoenix, TRR в протестированных модулях DDR5 SK hynix имела конечное число отслеживаемых агрессоров - превысил лимит, и защита перестаёт работать. Авторы призвали производителей перейти к открытым механизмам защиты, как это принято для криптографических стандартов. Пока безуспешно.

ECC (Error-Correcting Code) - память с коррекцией ошибок исправляет однобитные ошибки и детектирует двухбитные. ECC стандартна в серверных системах, но отсутствует в потребительских GPU (включая RTX A6000, где GPUBreach был продемонстрирован). ECC не останавливает многобитные flips - исследования показали возможность обхода при множественных одновременных bit flip в одном кодовом слове. Для HBM-памяти (A100, H100, H200) on-die ECC включён по умолчанию, что объясняет устойчивость этих ускорителей.

PARA (Probabilistic Adjacent Row Activation) - при каждой активации строки контроллер с небольшой вероятностью обновляет соседние строки. В отличие от TRR, PARA не пытается отслеживать агрессоров - refresh соседей происходит случайно. Это делает PARA теоретически устойчивым к обходу через сложные паттерны. Цена - дополнительная нагрузка на контроллер и энергопотребление.

Увеличение частоты refresh - удвоение refresh rate (double refresh) вдвое сокращает окно для hammering. DDR5 уже использует 32 мс refresh вместо 64 мс DDR4. Побочный эффект - рост энергопотребления и снижение пропускной способности памяти.


Рекомендации по приоритету:

• Серверы и облако: ECC-память обязательна, мониторинг CECC (corrected errors) через IPMI/BMC
• GPU-инфраструктура: предпочитать HBM-ускорители (A100+) для security-sensitive workloads, ограничить мультитенантность на Ampere GDDR6
• Embedded/RT: оценить JENGA-эффект - включение mitigation может нарушить WCET

Что дальше: куда движутся аппаратные атаки на память​

Три одновременных доклада на IEEE S&P с GPU Rowhammer-эксплойтами до root - не аномалия, а индикатор зрелости направления. Атаки на память прошли классический цикл: proof of concept (2014) → обход защит (2020-2021) → полноценная эксплуатация на CPU (2022-2024) → переход на GPU (2025-2026).

Следующий фронт - память нового поколения. GDDR7, HBM3e, CXL-attached memory расширяют атакуемую поверхность. HBM защищён on-die ECC, но CXL-память, подключённая через fabric, создаёт новые возможности для cross-device hammering. RowPress и аналогичные timing-based атаки будут только усиливаться с ростом плотности ячеек.

Для практиков: Rowhammer - не академическая абстракция. Это работающий вектор эскалации привилегий, который уже сейчас влияет на архитектуру облачных deployments, выбор GPU-ускорителей и политики мультитенантности. Модель угроз без аппаратных атак на память - неполна.

Если хотите отработать низкоуровневые техники от воспроизведения Rowhammer до DMA-атак и side-channel анализа - на codeby.school есть курсы по аппаратному пентесту и бинарной эксплуатации. /proc/self/pagemap, performance counters, CUDA-эксплойты - всё с лабами.

Индустрия обращается с Rowhammer как с погодой: да, бывает, ну что поделать, это физика. NVIDIA ссылается на «общеотраслевую аппаратную проблему» вместо того, чтобы выпустить CVE на memory-safety баги в собственном драйвере, которые превращают bit flip в root shell. Производители DRAM прячут реализацию TRR за NDA, хотя исследователи раз за разом доказывают: каждый закрытый TRR-механизм ломается в течение 1-2 лет после выхода на рынок.

На практике ситуация хуже, чем в публикациях. Большинство организаций с GPU-кластерами для ML-задач не включают MIG-изоляцию, потому что она снижает утилизацию. Мультитенантность через MPS - стандартная практика для cloud-провайдеров, и это именно та конфигурация, которую эксплуатирует GPUBreach. Серверная ECC-память защищает CPU DRAM, но GDDR6 на тех же серверах с ускорителями - без ECC. Триллионная инфраструктура AI-вычислений работает на памяти с известным, фундаментально неустранимым физическим дефектом. Единственная причина, по которой мы не видим массовой эксплуатации, - порог входа для атакующего всё ещё высок. Но он снижается с каждой публикацией. Через два-три года Rowhammer-эксплойты для GPU будут автоматизированы так же, как сегодня автоматизированы SQL-инъекции. К этому моменту архитектуру уже поздно менять.