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

139 000 последовательных активаций строки DRAM - и бит переворачивается. Это не теория: Kim et al. показали это ещё в 2014 году (ISCA, «Flipping Bits in Memory Without Accessing Them»). А в сентябре 2025 года команда ETH Zurich выкатила атаку Phoenix - надёжный bit-flip во всех 15 протестированных модулях DDR5 (SK hynix), privilege escalation через PTE с медианой порядка 109 секунд (публикация COMSEC ETH Zurich). Каждая активация строки оставляет след в hardware performance counters процессора: LLC-miss на ядре, ACTIVATE-команда на контроллере памяти. И вот что важно - атакующему не нужны программные уязвимости. Три вектора без единого CVE в софте: эскалация привилегий через обход sudo (T1068, Privilege Escalation), компрометация RSA-2048 через искажение ключевого материала в памяти (повреждённый модуль факторизуется), произвольное чтение/запись через модификацию таблицы страниц (PTE). При Rowhammer-паттерне интенсивность HPC-событий возрастает на порядки. HPC-телеметрия - основной канал раннего детекта, но не серебряная пуля: она слепа к store-based и non-temporal паттернам, и без корреляции с CE-событиями EDAC/rasdaemon картина неполная. А стандартные SIEM и EDR аппаратный уровень вообще не видят.

Механика Rowhammer глазами инженера детекта​

Rowhammer эксплуатирует физическую близость ячеек DRAM: многократная активация одной строки (aggressor row) вызывает утечку заряда в соседних строках (victim rows), и биты меняют значение. Три стадии атаки - и каждая генерирует характерный аппаратный сигнал.

Memory profiling (Discovery). Атакующий определяет физическую адресацию строк DRAM - какие виртуальные адреса ложатся на соседние физические строки. CVE-2019-0174 (Red Hat: CVSS v3 base 3.8, severity Low по CVSS / Moderate по вендорской градации, CWE-205 - Observable Behavioral Discrepancy; в NVD CWE и CVSS-вектор не назначены) описывает logic condition в ряде процессоров Intel (i9-9900X, i9-9920X, i9-9960X и др.), позволяющую аутентифицированному пользователю вытащить частичную информацию о физических адресах через локальный доступ. На этой стадии атакующий генерирует нетипичный паттерн обращений к памяти - по сути System Information Discovery (T1082).

Cache bypass. Rowhammer требует прямых обращений к DRAM, минуя кэш-иерархию. Тут в ход идут clflush, clflushopt или uncacheable-маппинги. Сам flush в MEM_LOAD_RETIRED.L3_MISS не учитывается - счётчик инкрементирует последующая demand-загрузка вытесненной строки. В hammer-цикле flush+load каждая итерация даёт ровно один LLC-miss.

Repetitive access. Собственно «простукивание» строк. Паттерны: single-sided (одна aggressor row), double-sided (две aggressor rows, victim между ними - вероятность bit-flip значительно выше), multi-sided (фаззер Blacksmith для обхода TRR на DDR4). Каждый паттерн порождает массовые ACTIVATE-команды на контроллере памяти.

Задача Blue Team - ловить аномалии на стадиях cache bypass и repetitive access через hardware performance counters и события ECC-коррекции.

Требования к окружению для мониторинга​

Перед настройкой мониторинга проверьте, что инфраструктура соответствует минимальным требованиям:

• CPU: Intel Skylake и новее (Core i7-6700+, Xeon Scalable) для поддержки PEBS-совместимого события MEM_LOAD_RETIRED.L3_MISS:pp. Uncore-мониторинг IMC - серверные Xeon Scalable (Skylake-SP и новее). На AMD (Zen 2/3) PEBS отсутствует, используйте IBS: perf record -a -e ibs_op//p -c 10000 и counting-события типа ls_any_fills_from_sys.dram_io_all; PEBS-подобная точная выборка появилась только в Zen 4+. Uncore-эквивалент ACT_COUNT недоступен - детект строится на IBS + rasdaemon
• Платформа: Только bare-metal или VM с проброшенным vPMU (VMware vSphere vPMU, KVM с -cpu host,pmu=on). В публичных облаках (AWS EC2 кроме .metal, Azure, GCP) PMU не проброшен - perf stat -e MEM_LOAD_RETIRED.L3_MISS вернёт <not supported>, uncore PMU отсутствует вовсе. В таких средах остаётся только rasdaemon/EDAC, если ECC-события пробрасываются гипервизором
• OS: PEBS-события поддерживаются perf начиная с ядер 3.x; для Skylake-SP uncore IMC PMU нужно 4.9+, для стабильной поддержки Ice Lake/Sapphire Rapids uncore - 5.4+/5.15+. Проверять фактическую доступность через perf list | grep -i l3 и perf list | grep uncore_imc. Рекомендуется RHEL 8+ / Ubuntu 20.04+
• Пакеты: linux-tools-generic (Ubuntu) или perf (RHEL), rasdaemon (для ECC-мониторинга), msr-tools (опционально, для прямого чтения MSR при настройке OFFCORE_RESPONSE)
• Память: ECC обязательна для rasdaemon-детекции CE-событий. На non-ECC системах доступен только HPC-мониторинг без корреляции с bit-flip
• Привилегии: system-wide режим (-a) и uncore-счётчики требуют root (или CAP_PERFMON через setcap; CAP_SYS_PTRACE нужен только для символизации через /proc/<pid>/maps, не для счётчиков). По умолчанию kernel.perf_event_paranoid = 2–4 в большинстве дистрибутивов - для system-wide и uncore нужно sysctl -w kernel.perf_event_paranoid=-1 (или 0) и закрепить в /etc/sysctl.d/. Uncore-события работают только в system-wide режиме, поэтому требуют CAP_PERFMON (ядро 5.8+) / CAP_SYS_ADMIN на старых ядрах либо kernel.perf_event_paranoid ≤ 0
• Overhead: Overhead PEBS-sampling пропорционален частоте событий: при -c 10000 на memory-bound нагрузке с высокой частотой LLC-miss overhead может заметно превышать единицы процентов CPU. Period подбирайте так, чтобы частота семплов не превышала нескольких кГц на ядро - контролировать через perf stat и kernel.perf_event_max_sample_rate. rasdaemon - пренебрежимо малый overhead (обработка прерываний MCE). Постоянный мониторинг uncore через perf stat - как правило, незначительный overhead
• RAM мониторящей системы: зависит от длительности записи и частоты семплов; perf record с дефолтным буфером потребляет умеренный объём, но при длительной записи с высокой частотой событий данные могут заметно разрастись - рекомендую предварительно прогнать короткий тестовый запуск и оценить размер

Мониторинг hardware performance counters для обнаружения Rowhammer атак​

Core-level: Intel PEBS и MEM_LOAD_RETIRED.L3_MISS​

Событие MEM_LOAD_RETIRED.L3_MISS фиксирует demand-загрузки, промахнувшиеся мимо LLC (Last Level Cache) и ушедшие в DRAM. При Rowhammer каждое обращение к aggressor row вызывает cache flush с последующим повторным доступом - получаем массовый поток LLC-miss. Принцип heuristic-based detection на базе hardware performance counters позволяет идентифицировать потенциальных атакующих - аналогичный подход использует ANVIL (Aweke et al., 2016), описанный как программный метод мониторинга обращений к DRAM через HPC.

Для детекта - двухшаговый подход: system-wide захват с последующей атрибуцией к процессу.

# 1. System-wide захват LLC-miss с PEBS-точностью (10 сек)
perf record -a -e MEM_LOAD_RETIRED.L3_MISS:pp -c 10000 -- sleep 10

# 2. Смотрим, кто генерирует основную массу промахов
perf report --sort pid,comm,dso,sym

# 3. Real-time триаж без записи на диск - удобно для быстрого взгляда
perf top -e MEM_LOAD_RETIRED.L3_MISS:pp

Флаг -a - system-wide захват со всех ядер. Суффикс :pp включает PEBS (Precise Event-Based Sampling) - точная атрибуция к инструкции, а не приблизительная. Параметр -c 10000 - один семпл на каждые 10 000 событий, баланс между точностью и overhead.

perf report --sort pid,comm,dso,sym покажет, какой процесс, из какого бинарника и какой функции генерирует основную массу LLC-miss. Rowhammer-процесс будет доминировать в отчёте - он просто не может не доминировать при сотнях тысяч активаций. Для оперативного триажа perf top -e MEM_LOAD_RETIRED.L3_MISS:pp показывает топ-функции по LLC-miss в реальном времени - можно быстро определить PID подозрительного процесса без записи на диск.

Когда core-level недостаточно: uncore IMC и OFFCORE_RESPONSE​

MEM_LOAD_RETIRED.L3_MISS покрывает только demand-загрузки - операции чтения, инициированные стандартными mov-инструкциями. Rowhammer-варианты, использующие store-based паттерны (запись через mov [addr], reg с последующим clflush) или non-temporal stores (movntdq, movnti), этим счётчиком не ловятся. Это принципиальное ограничение core-level мониторинга hardware performance counters - нужны дополнительные источники.

OFFCORE_RESPONSE (core-level, конфигурируемый). Программируется через MSR 0x1A6/0x1A7 с масками для RFO (Read For Ownership - store-miss) и streaming stores. Perf поддерживает синтаксис perf stat -a -e 'cpu/event=0xb7,umask=0x01,offcore_rsp=<mask>/' -- sleep 10. Конкретная маска зависит от микроархитектуры - для каждой платформы сверяйтесь с Intel perfmon event database. Настройка - боль, но OFFCORE_RESPONSE покрывает store-паттерны, невидимые для MEM_LOAD_RETIRED.

Uncore IMC (серверные платформы). Счётчики контроллера памяти видят весь DRAM-трафик независимо от типа инструкций на ядре:

• UNC_M_CAS_COUNT.RD / UNC_M_CAS_COUNT.WR - CAS-операции чтения/записи на DRAM
• UNC_M_ACT_COUNT - активации строк DRAM (прямой индикатор row hammering)
• UNC_M_PRE_COUNT.ALL - precharge-команды

Запуск: perf stat -a -e uncore_imc_0/event=0x01/ -- sleep 10 (конкретный event code зависит от платформы, уточняйте через perf list). Uncore-счётчики не привязаны к ядру или процессу - это глобальный показатель. При аномалии на uncore-уровне нужен второй шаг: core-level PEBS для атрибуции к конкретному PID. Без этого вы знаете, что кто-то молотит память - но не знаете кто.

Детектирование Rowhammer через rasdaemon и события коррекции ошибок​

Hardware performance counters фиксируют паттерн обращений, но не сам bit-flip. Чтобы подтвердить, что Rowhammer действительно вызвал искажение данных, нужен мониторинг Correctable Errors (CE) через ECC-подсистему. Исследователи ETH Zurich отмечают, что on-die ECC (присутствующий во всех DDR5 UDIMM) усложняет атаку, но не делает её невозможной - Phoenix показал это на DDR5 UDIMM с on-die ECC. Тут есть неприятный нюанс: коррекции on-die ECC невидимы для ОС и не логируются rasdaemon, поэтому CE-канал детекта на таких системах отсутствует.

Дельта CE-событий как индикатор bit-flip​

rasdaemon - демон, который обрабатывает Machine Check Exceptions (MCE) и записывает дискретные CE/UE-события в SQLite-базу /var/lib/rasdaemon/ras-mc_event.db. Каждая запись содержит timestamp, номер контроллера памяти, адрес ошибки и количество. Установка: apt install rasdaemon && systemctl enable --now rasdaemon (Ubuntu) или yum install rasdaemon && systemctl enable --now rasdaemon (RHEL).

# Дискретные CE за последние 60 секунд
# Внимание: rasdaemon пишет timestamp в локальном времени с TZ-суффиксом,
# datetime('now') возвращает UTC - прямое сравнение даст неверный результат.
# Нормализуем:
sqlite3 /var/lib/rasdaemon/ras-mc_event.db \
  "SELECT id, timestamp, err_count, err_msg, label, mc, top_layer, middle_layer, lower_layer, address
   FROM mc_event
   WHERE datetime(substr(timestamp,1,19)) > datetime('now','localtime','-60 seconds')
   ORDER BY id DESC;"

# Или через CLI, если лень вспоминать SQL:
ras-mc-ctl --errors

Условие алерта: ≥10 CE за 60-секундное окно, при условии что события распределены по разным row/bank/address (поля top_layer, middle_layer, lower_layer в mc_event). Если платформа не декодирует row/bank (поля пусты), критерием служит число уникальных address в окне; при отсутствии и адресов - корреляция по DIMM label. Повторяющиеся CE по одному physical address исключайте - это деградация ячейки (кандидат на page-offline через memory_failure). Обязательно ведите whitelist известных «шумящих» DIMM. По данным Schroeder et al. (SIGMETRICS 2009), более 8% DIMM фиксируют хотя бы одну CE в год, среднее - порядка нескольких тысяч CE на затронённый DIMM в год, при этом ошибки сильно кластеризуются во времени. Порог delta > 0 на парке серверов завалит вас false positives. А вот серия CE по разным адресам за секунды - это уже аномалия, которую стоит копать.

Сырые sysfs-счётчики (/sys/devices/system/edac/mc/mc*/ce_count) показывают кумулятивное значение CE с момента загрузки. Для пороговой детекции из них вычисляется дельта: текущее значение минус предыдущее за фиксированный интервал. Но sysfs не хранит timestamp и адрес ошибки - rasdaemon предпочтительнее, поскольку каждая запись в mc_event - отдельное событие с полным контекстом.

Корреляция CE с HPC. Если rasdaemon фиксирует рост CE одновременно с аномальным ростом MEM_LOAD_RETIRED.L3_MISS или UNC_M_ACT_COUNT - это сильный индикатор Rowhammer-активности. CE без HPC-аномалии - скорее деградация памяти или единичный cosmic ray (да, космические лучи реально переворачивают биты - но не по десять штук за минуту). HPC-аномалия без CE - подозрительный паттерн доступа, не достигший bit-flip: ранняя стадия атаки или работающая TRR-защита.

Построение baseline и пороги аномалий для мониторинга DRAM атак​

Робастные квантили вместо σ-подхода​

Распределение LLC-miss тяжелохвостое и автокоррелированное: штатная нагрузка (GC-паузы JVM, перестроение индексов БД, компиляция) порождает выбросы, которые при классическом σ-подходе дают ложные срабатывания. Я рекомендую робастные квантили или MAD-нормировку.

Шаг 1: сбор 24-часового baseline по каждому серверу. Запуск perf stat -a -e MEM_LOAD_RETIRED.L3_MISS -I 1000 -x, -o baseline.csv -- sleep 86400 записывает одно значение в секунду, 86 400 точек за сутки.

Шаг 2: расчёт P99.9 квантиля по полученному массиву. Всё, что выше P99.9, рассматривается как аномалия. Квантильный подход устойчив к выбросам и не требует допущений о нормальности распределения.

Альтернатива: MAD-нормировка (Median Absolute Deviation). MAD = median(|Xi - median(X)|). Порог аномалии: Xi > median(X) + k * MAD, где k = 5–10 в зависимости от профиля нагрузки. MAD устойчивее σ для heavy-tailed распределений.

Если всё-таки используете σ-подход (стандартное отклонение), минимальные пороги сильно зависят от типа нагрузки:

• Web/DB-серверы (прерывистая нагрузка): 4σ, с обязательным требованием непрерывности аномалии минимум 20–30 секунд (окно должно превышать типичную длительность GC-пауз в baseline)
• Compute-узлы (HPC, ML-задачи, постоянная высокая нагрузка): 6σ, непрерывность минимум 10 секунд

Требование непрерывности - критичная штука: единичный всплеск LLC-miss (GC-пауза, кэш-промах при холодном старте приложения) не должен генерировать алерт. Rowhammer-паттерн отличается устойчивым повышенным уровнем на протяжении секунд или минут - это не всплеск, это плато.

Пороги uncore-счётчиков (UNC_M_ACT_COUNT) рассчитываются аналогично, но baseline сильно зависит от модели памяти, числа каналов и ранков. Одинаковый порог для серверов с разной конфигурацией памяти не работает - калибровка на каждый хост обязательна.

Интеграция в SOC: workflow от алерта до расследования​

Workflow при срабатывании порога HPC или CE-дельты:

1. Алерт. Скрипт мониторинга фиксирует превышение P99.9 по LLC-miss или ≥10 CE за 60-секундное окно по разным address/row/bank (исключая повторы по одному physical address)
2. Обогащение. System-wide PEBS-захват: perf record -a -e MEM_LOAD_RETIRED.L3_MISS:pp -c 10000 -- sleep 10 с последующей атрибуцией через perf report --sort pid,comm,dso,sym
3. Триаж. Определение PID и командной строки подозрительного процесса. Главный вопрос: это легитимный процесс (база данных, build system, научные вычисления) или неизвестный бинарь?
4. Подтверждение. Корреляция с rasdaemon CE-событиями. Совпадение HPC-аномалии с ростом CE = высокая уверенность в Rowhammer-активности
5. Реагирование. Изоляция хоста, снятие дампа памяти процесса, анализ бинарника на характерные Rowhammer-сигнатуры (циклы с clflush/clflushopt, обращения к массивам с шагом, равным размеру строки DRAM)

Автоматизация: скрипт на bash или python, вызывающий perf stat -e MEM_LOAD_RETIRED.L3_MISS -I 1000 -- sleep 5 каждые N секунд, парсящий вывод и сравнивающий с baseline. При превышении - запуск детальной записи и алерт. HPC-данные не попадают в стандартные SIEM-логи напрямую, но метрики можно отправлять в Prometheus/Grafana с Alertmanager-интеграцией для корреляции с остальной телеметрией.

Сравнение методов обнаружения bit flip атак​

Метод	Преимущества	Ограничения	Когда использовать	Когда НЕ использовать
Core HPC (PEBS)	Атрибуция к PID; PEBS-точность; работает на десктопных CPU	Только demand-loads; не ловит store-based и non-temporal	Первичный триаж и определение PID	Store-heavy Rowhammer; ARM-платформы
Uncore IMC	Весь DRAM-трафик; нет слепых зон по типу инструкций	Нет атрибуции к процессу; требует серверный Xeon	Непрерывный baseline-мониторинг на серверах	Десктопы без uncore PMU
rasdaemon CE	Прямое подтверждение bit-flip; минимальный overhead	Пост-фактум; требует ECC; не детектит до bit-flip	ECC-серверы; корреляция с HPC-аномалиями	Non-ECC системы
OFFCORE_RESPONSE	Покрывает RFO и store-miss; настраиваемые маски MSR	Сложная конфигурация; vendor-specific event codes	Углублённый анализ после первичного алерта	Постоянный фоновый мониторинг

Чеклист для Blue Team: мониторинг аппаратных атак на память​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

ECC-память на серверах создаёт ощущение защищённости от Rowhammer - и это одна из самых опасных иллюзий в инфраструктурной безопасности. Rank-level SECDED ECC на серверных ECC-DIMM молча корректирует одиночные bit-flip (CE видны через rasdaemon), а on-die ECC в DDR5 UDIMM корректирует ошибки полностью невидимо для ОС. В обоих случаях Rowhammer-активность на ранних стадиях проходит незамеченной. Phoenix тестировался на DDR5 UDIMM с on-die ECC, а не на серверных ECC-DIMM с SECDED - но расслабляться не стоит. Большинство инфраструктурных команд не мониторят ни hardware performance counters, ни CE-rate через rasdaemon. HPC-телеметрия - мёртвая зона между стандартным SOC-стеком (SIEM, EDR, NTA) и физическим уровнем. При этом порог входа для атакующего снижается: TRRespass, Blacksmith лежат на GitHub, а Phoenix достигает privilege escalation через PTE с медианой порядка 109 секунд на протестированных модулях.

В ближайшие пару лет мониторинг DRAM-событий через perf и rasdaemon перейдёт из категории «академический эксперимент» в «гигиенический минимум» для серверной инфраструктуры - примерно как мониторинг SMART для дисков десять лет назад. Запустите perf stat -a -e MEM_LOAD_RETIRED.L3_MISS -I 1000 -- sleep 60 на любом из своих серверов прямо сейчас. Если вы видите цифры - у вас есть точка старта. Если <not supported> - вы в облаке без PMU, и ваш единственный канал детекта - rasdaemon. Вопрос в том, кто начнёт первым: ваша Blue Team или регулятор.