При профилировании латентности банков DDR4 на FPGA-стенде с контроллером LiteDRAM я получил разброс времени отклика одного и того же физического адреса при активной логике Target Row Refresh - шестикратное отклонение от базовой линии. Шесть иксов. На десктопе такой джиттер поглотится буферами переупорядочивания и кешами, никто и не заметит. А вот для контроллера тормозной системы с фиксированным WCET-бюджетом в сотни наносекунд - это нарушение контракта, на котором стоит вся safety-логика.
RowHammer атака на DRAM перестала быть чисто академической проблемой целостности данных. Она бьёт по предсказуемости - свойству, без которого real-time системы превращаются в дорогие генераторы случайных чисел. Ниже - разбор того, как защитные механизмы DRAM порождают угрозу не менее серьёзную, чем сама уязвимость.
Физика RowHammer: почему уязвимость DRAM памяти фундаментальна
RowHammer - не ошибка прошивки и не конструктивный просчёт конкретного производителя. Это прямое следствие физики масштабирования. Каждый бит DRAM хранится в конденсаторе, площадь которого сокращается с каждым технологическим узлом. Заряд конденсатора определяет значение «0» или «1», а утечка заряда - неизбежный физический процесс, компенсируемый периодическим refresh: стандартно каждые 64 мс для DDR4 при 85 °C и 32 мс для DDR5.При активации строки (команда ACTIVATE) напряжение подаётся на wordline, связанный со всеми ячейками строки. Данные из ячеек уходят в row buffer через sense amplifier, затем записываются обратно - часть каждого штатного чтения/записи. Проблема - в интенсивном повторении: многократная активация (row hammering) одной строки вызывает электромагнитные наводки на соседние wordline, ускоряя утечку заряда в victim-строках.
Три физических механизма утечки между строками (Kim et al.):
- Электромагнитная связь (coupling) - переключение wordline индуцирует шум на соседних линиях через паразитную ёмкость
- Bridging - образование проводящих каналов между соседними проводниками при многократных переключениях
- Hot carrier injection - длительное переключение wordline приводит к инжекции горячих носителей, усиливающей утечку в соседних ячейках
От single-sided к non-uniform паттернам
Первые атаки использовали single-sided hammering - активацию одного агрессора рядом с жертвой. Double-sided hammering (два агрессора по обе стороны victim-строки) увеличил вероятность bit flip на порядок. Производители ответили Target Row Refresh (TRR), и паттерны атак эволюционировали: вместо равномерных обращений к одной-двум строкам - non-uniform последовательности из десятков и сотен агрессоров с различной частотой, фазой и амплитудой обращений.Именно non-uniform паттерны стали ключом к обходу всех существующих аппаратных защит. По сути, задача RowHammer-эксплуатации превратилась в задачу фаззинга параметров доступа к памяти.
Обход защиты от RowHammer: от Blacksmith до Phoenix
Target Row Refresh - основной аппаратный механизм защиты DDR4 и DDR5. TRR отслеживает часто активируемые строки при помощи конечного числа счётчиков и принудительно обновляет соседние victim-строки при достижении порога. Реализация TRR проприетарна, варьируется между Samsung, Micron, SK Hynix и не документирована публично. В этой проприетарности и конечности ресурсов - корень уязвимости.CVE-2021-42114 и фаззер Blacksmith
Атака TRRespass первой показала: одновременный hammering нескольких не-смежных строк «забивает» счётчики TRR, оставляя victim-строки голыми. CVE-2021-42114 зафиксировал следующий этап эскалации - полный TRR обход защиты через автоматизированный фаззинг.Blacksmith - фаззер от исследователей ETH Zurich, Vrije Universiteit Amsterdam и Qualcomm (лежит на GitHub). Blacksmith генерирует non-uniform паттерны доступа, синхронизирует их с командой REFRESH и ищет «слепые зоны» конкретной реализации TRR. Фаззинг гоняли по 12 часов на каждом модуле; лучший паттерн (по количеству вызванных bit flip) затем применяли к непрерывной области памяти в 256 МБ.
Характеристики CVE-2021-42114:
| Параметр | Значение |
|---|---|
| CVSS | 9.0 (CRITICAL) |
| Вектор | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H |
| CWE | CWE-20 (Improper Input Validation) |
| Affected | Samsung DDR4 SDRAM, Samsung LPDDR4(X), Micron LPDDR4 (согласно NVD CPE) |
Разбор вектора: AV:N - атака не требует локального физического доступа; теоретически реализуема через любой процесс с доступом к памяти (браузерный JS-движок, гостевая VM), хотя оригинальное исследование Blacksmith использует native-доступ. AC:H - требуется высокая сложность: подбор паттерна под конкретный модуль и реализацию TRR. PR:N и UI:N - ни привилегий, ни взаимодействия пользователя. S:C (Changed scope) - bit flip в памяти одного процесса затрагивает данные другого, включая ядро ОС. Воздействие на конфиденциальность, целостность и доступность - максимальное (C:H/I:H/A:H).
Результат: Blacksmith вызвал bit flip на всех 40 протестированных PC-DDR4 модулях, покрывающих трёх крупнейших производителей (Samsung и Micron указаны в NVD CPE; SK Hynix в CPE не фигурирует, но упоминается в оригинальной работе). В ряде случаев - тысячи bit flip за секунды. CWE-20 (Improper Input Validation) тут читается как неспособность TRR распознать non-uniform паттерны обращений как подозрительные - хотя NVD не раскрывает обоснование выбора именно этого CWE.
Сорок из сорока. Ноль устоявших модулей. Стоит вдуматься.
DDR5 под ударом: деградация памяти нового поколения
DDR5 получила укороченный интервал refresh, усиленную TRR-логику и on-die ECC. С 2020 по 2024 год модули DDR5 считались защищёнными от RowHammer. Атака Phoenix это опровергла.Исследователи ETH Zurich совместно с Google - на открытых FPGA-платформах для DDR5 RDIMM и SO-DIMM от Antmicro - провели реверс-инжиниринг TRR в 15 модулях DDR5 SK Hynix (2021–2024, 16–64 ГБ). Два найденных паттерна:
Короткий: после 128 TRR-отслеживаемых обращений возникает окно из 64 обращений со сниженной защитой. Длинный: 2608 маскировочных обращений перед атакующим окном.
Оба следуют одной логике: массив «отвлекающих» обращений, насыщающих счётчики TRR, после чего - серия hammering по реальной цели. Короткий паттерн оказался эффективнее.
Практические сценарии (AMD Ryzen 7 7700X, Zen 4, Ubuntu 20.04):
| Сценарий | Цель | Результат |
|---|---|---|
| PTE (Page Table Entry) | Произвольное чтение/запись RAM | Успешен на всех 15 модулях |
| RSA-2048 | Извлечение приватного ключа | Частичный успех (до 1+ часа) |
| sudo bypass | Эскалация привилегий | Частичный успех |
PTE-атака - T1068 (Exploitation for Privilege Escalation): модификация записи таблицы страниц даёт полный контроль над адресным пространством. Модификация данных в RAM - T1565.003 (Runtime Data Manipulation, Impact). Массовые bit flip, приводящие к отказу, можно отнести к T1499.004 (Application or System Exploitation, Impact) - эксплуатация логики DRAM-контроллера и refresh-механизмов для достижения отказа, хотя точный маппинг дискуссионен.
По данным исследования Phoenix, текущие защиты на основе TRR и ECC - вероятностные контрмеры с недостаточной энтропией, не способные надёжно противостоять целеустремлённому атакующему. Иными словами: защита работает «в среднем», а атакующему «в среднем» не нужно.
JENGA-эффект: защиты от RowHammer разрушают предсказуемость WCET
Здесь начинается самое интересное - влияние RowHammer-митигаций на детерминированность выполнения задач в real-time системах. Я называю это JENGA-эффектом: каждая «защитная» прослойка для предотвращения bit flip делает тайминг-поведение памяти менее предсказуемым. Как в настольной игре - вытаскиваешь блок, и конструкция стоит, пока стоит. Но с каждым уровнем устойчивость падает.Недетерминированный refresh как side-channel атака на память
В системах жёсткого реального времени (hard real-time) каждая задача получает бюджет worst-case execution time. Планировщик гарантирует: задача уложится в WCET, дедлайн не будет пропущен. На этом стоит сертификация в авиации (DO-178C), автомобильной электронике (ISO 26262), промышленной автоматике (IEC 61508).WCET-анализ предполагает, что латентность доступа к DRAM ограничена сверху известной константой: совокупность tRCD, tCAS, tRP и периодического tREFI. Параметры зафиксированы в спецификации JEDEC.
TRR разрушает это предположение тремя путями.
Блокировка банка. TRR-refresh блокирует банк памяти на время tRFC (порядка 350 нс для 16 Гб DDR4). Штатные обращения к этому банку ждут в очереди.
Непредсказуемый момент. TRR-refresh вставляется не по расписанию, а в ответ на обнаруженный паттерн обращений. Момент зависит от поведения ВСЕХ задач в системе - включая задачи с низким приоритетом, обращающиеся к соседним строкам того же банка.
Неизвестное количество. Число дополнительных refresh варьируется в зависимости от реализации TRR (проприетарной, недокументированной) и интенсивности обращений.
В терминах real-time теории TRR создаёт неограниченную priority inversion на уровне железа: низкоприоритетная задача, чьи обращения к памяти «засвечиваются» TRR-счётчикам, может вызвать дополнительный refresh, блокирующий банк для высокоприоритетной safety-задачи. Priority inversion в софте - известная проблема с известными решениями. Priority inversion в железе, спрятанная внутри проприетарного TRR - совсем другая история.
Тайминг-атаки на DRAM через TRR - отдельный вектор. Измеряя латентность своих обращений, атакующий получает информацию о паттернах доступа других процессов: повышенная латентность → TRR активировала refresh → кто-то интенсивно работает с соседними строками. Side-channel атака на память в чистом виде. Формального маппинга в MITRE ATT&CK для тайминг-side-channel на DRAM нет; ближайший кандидат - T1497.001 (System Checks), где тайминг-измерения используются для обнаружения активности других процессов.
Каскадная деградация тайминга в real-time планировщиках
Типичная конфигурация безопасности оперативной памяти включает несколько уровней:- Увеличенная частота refresh (tREFI сокращён вдвое) - удваивает долю времени на обновление
- TRR - добавляет непредсказуемые дополнительные refresh при обнаружении hammering
- ECC-скрабблинг - периодическая проверка и исправление ошибок, блокирующая банк на время scrub
Исследователи из Амстердамского свободного университета показали ещё одну грань: ECC-коррекция создаёт измеримый тайминг-side-channel. При исправлении ошибки возрастает время чтения - задержка «вполне измерима и заметна» (их формулировка). Они же продемонстрировали, что три одновременно изменённых бита проходят мимо ECC-детектора (SECDED). ECC - ненадёжная защита от целенаправленной RowHammer-атаки.
Итого каждый «защитный» блок в башне JENGA добавляет непредсказуемости. Убери блок - bit flip. Оставь - непредсказуемый тайминг. Для десктопа незаметно. Для системы с жёстким real-time - неприемлемо.
Атаки на встраиваемые системы: от LeapFrog до safety-critical
LeapFrog: контроль потока выполнения через bit flip
Исследование LeapFrog (2024, arxiv) вводит принципиально новый тип RowHammer-гаджета, нацеленный на control flow integrity: атакующий модифицирует сохранённый Program Counter (PC) в стеке. При вызове функции адрес возврата записывается в стек и в какой-то момент оказывается в DRAM. Bit flip в этом адресе «перепрыгивает» выполнение через security-critical участок кода - отсюда название.Ключевые результаты:
- OpenSSL: bit flip в сохранённом PC пропускает раунды шифрования, раскрывая plaintext
- TLS handshake: в клиент-серверном сценарии атакующий пропускает верификацию сертификата на стороне клиента (результаты авторов, arxiv, 2024)
- Post-Quantum Cryptography: сканирование Open Quantum Safe инструментом MFS (на базе Intel Pin) выявило множество LeapFrog-гаджетов - участков кода, где bit flip в PC приводит к полезному для атакующего пропуску логики, а не к segfault
Для автоматизации поиска гаджетов авторы создали MFS - инструмент на базе Intel Pin, который динамически анализирует бинарный код, перебирает возможные bit flip в сохранённом PC и определяет, какие из них приводят к пропуску security-critical блоков вместо краша. Ручной анализ превращается в систематический фаззинг.
Сценарии эксплуатации: автомобили, PLC, телеком
Зачем атаковать real-time систему через RowHammer?Автомобильные ECU. LPDDR4 - стандартная память в ADAS-контроллерах. CVE-2021-42114 перечисляет Samsung LPDDR4 и Micron LPDDR4 в affected products - автомобильный контекст в CVE не упоминается напрямую, но эти типы памяти широко применяются в ADAS, что делает сценарий релевантным. Bit flip в данных лидара или камеры ведёт к ошибке распознавания объектов. TRR-джиттер в момент расчёта дистанции торможения - к нарушению дедлайна safety-задачи.
Промышленные PLC. Контроллеры нередко работают с DDR4 без ECC - ради экономии. RowHammer через скомпрометированный модуль I/O (вектор Impact, предположительно T1499.004) может модифицировать управляющие переменные, вызывая физическое повреждение оборудования. Тут не данные утекают - тут турбина идёт вразнос.
Телеком (5G baseband). Базовые станции с DDR5 - потенциальная цель. Phoenix подтвердила уязвимость DDR5. Нарушение тайминга в real-time обработке сигналов - denial of service на физическом уровне.
Облачная инфраструктура. Мультитенантные серверы на DDR4 - подтверждённый вектор. Blacksmith вызвал bit flip на всех 40 модулях. Из одной VM атакующий может модифицировать данные соседней - RowHammer как VM escape. Если bit flip затронет область, где хранится firmware контроллера BMC (T1495, Firmware Corruption) - восстановление потребует физического доступа к серверу.
Практическое профилирование тайминг-джиттера от TRR
Вывод - распределение латентности в тактах процессора. В стационарном режиме ожидается узкий пик порядка 200–350 тактов на современных CPU. Записываем как baseline.
Шаг 3: параллельный hammering. Из второго потока (на отдельном ядре, но в том же банке DRAM - нужен предварительный reverse engineering DRAM address mapping) запускаем интенсивные обращения к строкам, соседним с измеряемой. Повторяем измерения шага 2 одновременно с hammering.
Шаг 4: анализ распределения. Сравниваем гистограммы baseline и hammering. Выбросы в «хвосте» под нагрузкой - моменты TRR-refresh. Разница между baseline-пиком и максимальным выбросом - нижняя оценка TRR-индуцированного джиттера. Если эта разница превышает запас WCET-бюджета safety-задачи - система подвержена JENGA-эффекту.
Для анализа на уровне DDR-команд (а не опосредованно через CPU) используйте FPGA-платформы: Google/Antmicro DDR5 Tester для DDR5 RDIMM/SO-DIMM или LiteX/LiteDRAM для DDR4. Они позволяют отправлять произвольные ACTIVATE, PRECHARGE, REFRESH напрямую к DRAM и наблюдать тайминг-ответы чипа, включая моменты вставки TRR-refresh. Единственный способ получить абсолютно чистые данные без шума процессорного pipeline - я на своём стенде убедился в этом, когда разница между CPU-измерениями и FPGA-данными достигала 40%.
Митигация: безопасность оперативной памяти в real-time контексте
PRAC: детерминированный подсчёт активаций
PRAC (Per Row Activation Counting) - стандарт, утверждённый JEDEC для будущих DDR5 и LPDDR6. В отличие от вероятностного TRR, PRAC отслеживает активации каждой строки детерминированно. При достижении порога генерируется alert, контроллер выполняет превентивный refresh.Для WCET-анализа разница принципиальная: refresh по фиксированному порогу (N активаций) - предсказуемая величина, которую можно включить в расчёт верхней границы латентности. TRR этого не позволяла - её поведение зависело от недокументированных эвристик.
Но текущие DDR5-модули PRAC не поддерживают. До массового появления PRAC-совместимой памяти - несколько лет.
Архитектурные решения для текущего оборудования
| Мера | Влияние на WCET | Защита от bit flip | Сложность |
|---|---|---|---|
| Изоляция банков DRAM | Предсказуемый | Не защищает от bit flip, только от тайминг-влияния | Средняя |
| Программный refresh | Предсказуемый | Частичная | Высокая |
| ECC + фиксированный scrub | Предсказуемый | Высокая | Средняя |
| PRAC (будущее) | Предсказуемый | Высокая | Требует нового HW |
| TRR (текущий) | Непредсказуемый | Недостаточная | Встроен в DRAM |
Изоляция банков. Safety-critical задача и остальные задачи - в разных банках DRAM. TRR-refresh одного банка не блокирует другой. Требуется контроль над физическим распределением памяти: частично поддерживается RTOS и гипервизорами (Xen dom0less, Jailhouse), а также через cache coloring в Linux.
Явное управление refresh. Ряд контроллеров памяти позволяет отключить автоматический TRR и управлять refresh программно. Тайминг становится полностью предсказуемым, но ответственность за защиту от bit flip переходит к разработчику - надо обеспечить достаточную частоту refresh для всех строк. Ручной режим - палка о двух концах.
ECC с фиксированным scrub-расписанием. Вместо фонового scrubbing (который «крадёт» циклы в произвольные моменты) - scrub по фиксированному расписанию, встроенному в WCET-бюджет. Scrub занимает известное время, происходит в известный момент - WCET-анализатор его учитывает.
Мониторинг. В соответствии с NIST CSF DE.AE-01 - установление базовой линии поведения памяти и алертинг при аномалиях (шаг 4 профилирования). ID.AM-01 требует инвентаризации аппаратных активов - для safety-critical систем это означает фиксацию модели и поколения TRR каждого модуля памяти и проверку статуса по CVE-2021-42114.
Ни один из текущих стандартов safety-сертификации - ISO 26262, DO-178C, IEC 61508 - не требует учёта TRR-индуцированного джиттера в WCET-анализе. Сертификационные лаборатории не тестируют поведение памяти под RowHammer-нагрузкой. Это слепое пятно опаснее самой RowHammer-уязвимости, потому что создаёт ложную уверенность: система проходит сертификацию с одним тайминг-профилем, а в поле работает с другим - тем, который TRR формирует под реальной нагрузкой.
PRAC устранит часть проблемы - детерминированный подсчёт закроет «слепые зоны» TRR. Но до массового перехода на PRAC-совместимую память в embedded-сегменте пройдёт не менее трёх-пяти лет, и всё это время safety-critical контроллеры на DDR4 и текущих DDR5 остаются в зоне, где формально верифицированный WCET может быть нарушен аппаратным механизмом, о котором разработчик не подозревает.
За полтора года работы с профилированием refresh-поведения на FPGA-стендах я пришёл к неудобному выводу: индустрия safety-critical embedded и исследования аппаратной безопасности DRAM существуют в параллельных мирах. Одни считают память «просто работающей». Другие ломают все существующие защиты поколение за поколением. Инцидент на стыке этих миров - вопрос времени. Проверьте свой стенд кодом из раздела профилирования. Если хвост распределения вылезает за WCET-бюджет - у вас та же проблема, что я увидел на LiteDRAM. Только вы, возможно, ещё об этом не знаете.
