Непривилегированная программа на видеокарте NVIDIA берёт root на всём хосте за минуту

Вы арендовали в облаке видеокарту – RTX A5000, обычная рабочая станция под инференс. На той же карте по соседству крутится чужая задача: GPU в облаке шарят по времени, это норма. Сосед вашу память не трогает – прав у него нет, IOMMU на месте, ECC включён, всё ровно так, как советует NVIDIA против Rowhammer. Он просто час гоняет свой CUDA-код, который читает собственные ячейки по кругу. А спустя минуту после того, как нашёл нужную строку памяти, у него root на хост-машине, где стоит ваша карта.

Это не лаборатория с отключёнными защитами и не мысленный эксперимент. Это GPUThor – атака, которая делает именно то, от чего NVIDIA рекомендует защищаться включением ECC, пробивая при этом сам ECC. Десять лет Rowhammer на видеопамяти считали недоразумением: флипов было так мало, что коррекция ошибок закрывала тему. Разберём, как исследователи из Университета Торонто подняли счёт в двадцать три тысячи раз и превратили рекомендованную вендором защиту в опору для эксплойта.

Десять лет GPU-Rowhammer был игрушкой

Rowhammer – это дефект чтения-возмущения в DRAM: если быстро и часто активировать одну строку ячеек (агрессор), соседняя строка (жертва) теряет заряд, и в ней переворачиваются биты. На процессорной DDR-памяти этим сносят песочницы, вытаскивают ключи и поднимают привилегии больше десяти лет. На видеопамяти GDDR6 всё началось только в прошлом году – и до сих пор выглядело беззубо.

Цифры объясняют, почему на это махнули рукой. Первая GPU-атака, GPUHammer, выбила на RTX A6000 два флипа на банк – шестнадцать переворотов на гигабайт. Следом GeForge и GPUBreach дали 18 и 45 флипов на гигабайт, GDDRHammer улучшил до 758. А процессорный Blacksmith на той же физике Rowhammer выбивает на DDR4 до 550 000 флипов на гигабайт – на три порядка больше. При такой нищете флипов включение ECC на видеокарте закрывало вопрос: коррекция чинит одиночную ошибку, а двойную ловит, и до практического эксплойта дело просто не доходило. Отсюда и официальная позиция NVIDIA: включите ECC – это основная защита от GPU-Rowhammer.

GPUThor эту позицию обнуляет. На той же A6000 он даёт не 16, а 114 488 флипов на гигабайт; на A5000 – 377 552, ровно в 23 597 раз больше GPUHammer и вплотную к худшему случаю процессорной DDR4. И это не тюнинг старого приёма, а другой класс удара.

Видеокарта, которая склеивает удары в один

Вся разница между нищими прошлыми атаками и GPUThor держится на одном слове: неравномерность. Процессорный Blacksmith лупит агрессора гораздо чаще, чем ложные строки (decoy), которыми забивает счётчик внутренней защиты DRAM. Прошлые GPU-атаки били равномерно – агрессор и ложные строки с одинаковой частотой, – и половину времени тратили впустую. Казалось бы, перенеси неравномерный паттерн с CPU на GPU – и всё. Не всё: видеокарта устроена так, что наивный перенос схлопывается обратно в равномерный.

Виновата оптимизация под пропускную способность. Тридцать два потока варпа идут по памяти в жёстком локстепе, и графический конвейер агрессивно склеивает их обращения (coalescing), чтобы не гонять шину зря. Документация NVIDIA признаёт склейку на уровне L1 внутри варпа, но про уровень L2 и контроллер памяти молчит. А для Rowhammer это ядро проблемы: если повторные обращения к строке-агрессору сливаются в одну активацию DRAM, то интенсивность, ради которой всё затевалось, испаряется. Прежде чем строить неравномерный паттерн, склейку пришлось реверсить.

Насколько это ловушка, видно по прошлой атаке GeForge. Она заявляла неравномерный паттерн на три такта, до тринадцати ударов по агрессору за цикл, – и молча провалилась ровно здесь. Повторы шли внутри одного варпа, склейка схлопнула их в пару активаций на такт, и «неравномерный» паттерн выродился в равномерный: флипов у GeForge вышло всего в 1.1 раза больше, чем у примитивного GPUHammer, и меньше, чем у честно-равномерного GPUBreach. Кто-то уже пробовал перенести приём с процессора на видеокарту – и не заметил, что она тихо съела всю его интенсивность.

Разные варпы, разные кэш-линии

Реверс сделали timing-side-каналом: гоняли обращения мимо кэшей и мерили время одного круга паттерна. Чтение шло инструкцией ld.volatile, а строка выбрасывалась из L2 инструкцией discard:

ld.volatile   чтение мимо L1
discard        выброс строки из L2

Базовый равномерный 9-сторонний паттерн (3 варпа × 3 потока, один агрессор и восемь ложных строк) давал круг в 484 нс – это честные девять активаций DRAM. Дальше начались открытия. Когда повторные удары по агрессору добавляли внутри одного варпа, круг падал до 469 нс: активаций стало меньше девяти, то есть повторы схлопнулись в контроллере памяти и лишних активаций не породили. Внутриварповые повторы для неравномерного хаммеринга бесполезны – это первый приговор.

Повтор из разных варпов, но по той же кэш-линии, дал скачок до 502 и 573 нс: discard из первого варпа вытесняет линию, повторный запрос из второго ловит эту возню, латентность улетает за пределы времени активации, и синхронизация паттерна с обновлением DRAM рассыпается. Тоже мимо. А вот повтор из разных варпов по разным кэш-линиям строки, разнесённым минимум на 128 байт, вернул круг к тем же 484 нс – склейки нет, активации сохраняются, и сверх базовых девяти прибавились удары по агрессору. Вот он, рабочий примитив: раскидать повторные удары по строке-агрессору между варпами и по независимым кэш-линиям внутри неё. Так неравномерность на GPU впервые заработала, дав 2–3× интенсивности агрессора против прошлых работ.

Но одного такта обновления памяти (tREFI, до 1.9 мкс в GDDR6) на разгон не хватило. Внутри единственного tREFI неравномерный паттерн вытянул лишь 2× интенсивности – 32.5 флипа против 21 у равномерного базового, рост в полтора раза, – а при 3× и 4× флипов становилось меньше: агрессор давят сильнее, но ложным строкам не остаётся места, они перестают попадать под сэмплирование защиты и та перестаёт обманываться. Потолок одного такта упёрся в 2×.

Защита срабатывает не каждый такт, а раз в семьдесят два

Чтобы пробить этот потолок, надо было знать то, что GDDR6 о себе не рассказывает: как часто внутренняя защита DRAM вообще делает свою работу. Target Row Refresh (TRR) сэмплирует часто активируемые строки и подновляет их соседей, гася утечку заряда; прошлые GPU-атаки исходили из того, что это происходит каждый такт tREFI, как на процессорной памяти. Проверить это на видеопамяти было нечем – ни логического анализатора, ни FPGA-стенда для GPU-памяти не существует. Тогда частоту TRR вытащили косвенно: брали известный флип и пытались воспроизвести его паттернами разной длины – от 1 до 36 тактов, по 50 попыток на длину, считая процент успеха.

Картина оказалась неожиданной. Флип надёжно воспроизводился на длинах 2, 3, 4, 6, 8, 9, 12, 18, 24 и 36 тактов, а дальше 36 практически пропадал – за 48 и 72 такта его поймали по одному разу. Почти все рабочие длины – делители 72. Вывод: TRR на этих GDDR6 срабатывает примерно раз в 72 такта tREFI, а не каждый такт, как считалось. Всё это время между срабатываниями защиты агрессора можно молотить безнаказанно.

Дальше интенсивность подняли жадно: в надёжных многотактовых паттернах (длины, делящие 72) ложные строки одну за другой заменяли ударами по агрессору, держа не больше одного удара на варп, чтобы не разбудить склейку. Короткие паттерны выдерживали до 5 ударов на такт, длинные (24 такта) – до 7. Компромисс между интенсивностью и вероятностью флипа сошёлся на шести тактах и 6.6 удара по агрессору за такт.

Пять тактов по агрессору, один по ложным строкам

Так собрался паттерн GPUThor. Он растянут на шесть тактов tREFI: первые пять забиты повторными ударами по агрессору – по одному на варп, чтобы обойти склейку, вперемешку с ложными строками, – а последний, шестой такт отдан целиком ложным строкам, которые в момент срабатывания TRR перегружают её счётчик и уводят настоящего агрессора из-под подновления. На круг обновления памяти это даёт до 110 000 активаций агрессора – в 6.6 раза больше, чем равномерный удар GPUHammer.

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

От шестнадцати флипов к тремстам семидесяти семи тысячам

Прежде чем бить, надо знать куда. Отображение виртуальных адресов на банки и строки GDDR6 нигде не задокументировано, поэтому его вытащили тем же timing-каналом: конфликт в буфере строки выдаёт адреса, попадающие в один банк, а время попадания в буфер – адреса одной и соседних строк внутри него. Так собирается набор строк, по которому и гоняют кампанию, последовательно назначая агрессором каждую строку банка и пробуя четыре комбинации данных жертвы и атакующего.

На четырёх картах Ampere (A4000, A4500, A5000, A6000), по четыре банка на карту и по 24 часа хаммеринга на банк, GPUThor выбил от 18 до 94 тысяч уникальных флипов на карту – против 19–658 у GPUHammer на тех же кристаллах. В пересчёте на гигабайт это от 72 000 до 377 552 флипов, то есть до 500 раз больше GDDRHammer и до 23 597 раз больше GPUHammer.

A5000 оказалась самой хрупкой: 377 тысяч флипов на гигабайт, 3584 флипа в час – по одному в секунду с одного банка. Прошлый рекорд GDDRHammer – 20 флипов в час, и то при параллельном долблении шести банков; GPUThor быстрее в 180 раз, работая по одному банку. Порог срабатывания (HCfirst) у всех карт лёг между 12.3 и 15.8 тысячи активаций, без прямой связи с общей хрупкостью карты. Плотность – 0.15–0.76 флипа на строку, так что несколько флипов в одной строке и кэш-линии становятся обычным делом, а вместе с ними и многобитные ошибки, на которых ломается ECC.

Эксплойт, который занимал сутки, теперь занимает минуту

Число флипов – не самоцель, оно напрямую режет время атаки. Классический GPU-эксплойт повышения привилегий портит запись в таблице страниц видеокарты (PTE), чтобы перенаправить обращение в чужую память; чтобы попасть флипом ровно в нужные биты номера страничного фрейма, нужно сперва найти подходящий флип, и это самая долгая, офлайновая часть.

На A6000 у GPUHammer поиск пригодного флипа занимал 1223.6 минуты – больше двадцати часов, а весь эксплойт от начала до root упирался в 21.9 часа. GPUThor роняет поиск флипа до 0.3 минуты, а весь эксплойт – до 1.1 минуты. На разных картах ускорение от 10 до 1200 раз, и почти везде общее время падает ниже полутора минут. Побочный выигрыш: из-за высокой плотности флипов GPUThor обходится набором строк в десятки штук там, где GPUHammer перебирал десятки тысяч, так что и поиск набора строк схлопывается с полутора часов до полуминуты. Онлайновая часть – раскладка PTE и финальный хаммеринг – у обеих атак одинаковые 0.2–0.3 минуты. Атака, которая раньше требовала непрерывно держать карту сутки, теперь укладывается в кофе-брейк.

ECC, у которого нашли два новых сайд-канала

Всё вышесказанное – с выключенным ECC, дефолтом многих облачных карт. Теперь тот же приём против включённого ECC. Алгоритм коррекции NVIDIA не раскрывает, стенда для его реверса нет, поэтому его вскрывали вслепую – хаммерили с включённым ECC и слушали побочные каналы.

Каналов нашли два, и оба новые. Первый – счётчик Volatile DRAM Correctable в nvidia-smi, доступный обычному пользователю. Второй тоньше: время выполнения ядра растёт с 4.5 до 7.6 мс, когда во время его работы ECC что-то починил, – доставка обновления счётчика драйверу CPU выдаёт факт коррекции. Опрос nvidia-smi стоит 178 мс и слишком груб, поэтому в кампаниях слушали именно времянку ядра.

ядро без ошибок          4.5 мс
ядро с коррекцией ECC     7.6 мс
опрос nvidia-smi          178 мс   (слишком медленно)

По этим каналам выяснили устройство коррекции: NVIDIA защищает 32 байта данных двумя независимыми кодами SECDED по одному байту, каждый прикрывает 16 байт. Одну ошибку в 16-байтном куске такой код чинит, две – детектирует, но не чинит (DUE), а три уже не ловит вовсе. Далась эта картина недёшево: реверсили вслепую, и одна кампания – просто нащупать DUE с включённым ECC – съедает около суток, а та, что ещё и определяет точное место каждого флипа маскированием бит, полтора дня на каждую комбинацию данных. На одном банке за это время всплыли 11 DUE и один SDC.

Один бит чинит, два роняет карту, три пропускает молча

Вот здесь рекомендованная защита выворачивается наизнанку. Поведение SECDED на видеокарте разложили по числу перевёрнутых бит, и каждая ветка играет на атакующего.

Один бит – коррекция молча чинит, ядро работает дальше. Два бита – детектируемая неисправимая ошибка: на архитектуре GA10X, где нет изоляции сбоев, она рубит все процессы на карте, и карта мертва до полного ресета. Казалось бы, это защита сработала – но у неё есть щель. DUE обслуживается лениво: между обнаружением ошибки и убийством ядра проходит около 10 мс, и всё это время испорченные данные ядру видны и потребляются им, в том числе для трансляции адресов через испорченную PTE. Десять миллисекунд – это вечность, когда финальная запись занимает меньше миллисекунды.

Инженерно ленивое обслуживание DUE – это выбор в пользу простоты драйвера и пропускной способности: не вставлять аппаратную блокировку на каждый сбой, гасить контекст асинхронно. Синхронное убийство ядра ровно в момент детекта DUE закрыло бы эту ветку эксплойта полностью, но стоило бы того самого интерлока на горячем пути. NVIDIA выбрала дешёвый путь и заплатила окном в 10 мс, которого атакующему хватает с запасом.

Три бита – отдельный подарок. Синдром тройной ошибки в коде Хэмминга путается с синдромом одиночной, поэтому SECDED считает её исправимой, «чинит» и переворачивает четвёртый бит в детерминированном месте – ядро не падает, а данные тихо испорчены (SDC, silent data corruption). Никакого краха, никакого сигнала: карта уверена, что всё хорошо. На мискоррекции при DUE, к слову, тоже всплывают лишние биты – от 2 до 10, в среднем 5, в фиксированных относительно исходных флипов местах, причём сами Rowhammer-флипы обычно сохраняются.

Защита, которая делает флип вечным

Прежде чем эксплойт с включённым ECC вообще становится возможен, надо разобраться с ремаппингом строк – механизмом, который на бумаге чинит дефектную память. При каждом DUE карта отправляет сбойную строку в отставку и подменяет запасной; запасных на банк восемь. Для атакующего это помеха: строку, в которой он поймал нужный флип, карта норовит убрать из-под ног. Обходов нашли два, и первый – издевательский. Если долбить банк дальше после восьми DUE, запасные строки кончаются, на девятом DUE взводится флаг отказа ремаппинга – и с этого момента ремаппинг выключен, а флипы в банке становятся постоянными: они воспроизводятся даже после ресета карты и перезагрузки хоста. Механизм, который должен был лечить память, исчерпавшись, сам делает дефект вечным и точно локализованным – ровно то, что нужно для надёжного эксплойта. На A6000 это состояние достигается за 18 часов хаммеринга.

Второй обход тоньше и ремаппинг не будит вовсе: биты ищут по одному. Двойной или тройной флип разбирают на составляющие, не срабатывая ими одновременно, – иначе получишь DUE и ремап. Интенсивность наращивают постепенно, пока в строке не мелькнёт первый флип, а затем перебирают биты по одному внутри каждого 32-байтного сегмента, маскируя все 256 бит, чтобы найти второй и третий флип, не потревожив уже найденные. На A6000 такой перебор занимает около четырёх суток – и отдаёт готовую тройку бит под тихую порчу, ни разу не уронив карту.

Минута до root даже с включённым ECC

С этими двумя свойствами – окном DUE и тихой порчей от тройного флипа – priv-esc собирается даже поверх ECC. Классический трюк с раскладкой таблиц страниц под ECC не работает: после флипа карта не даёт выделить память под новую таблицу. Обход – разложить таблицу страниц заранее, в предсказанное место назначения испорченной записи. Работают с записями 2 МБ страниц: из 128 бит такой записи под номер страничного фрейма отведено 25, и флип должен лечь именно в них:

| PFN 25 бит | флаги 8 бит (в т.ч. Aperture) | не используется 95 бит |

Раскладку строят примитивом cuMemMap, пользуясь тем, что в однопользовательском режиме физическое отображение непрерывно и предсказуемо: адрес назначения испорченной записи вычисляется заранее как исходный виртуальный адрес плюс известное смещение флипа. Сначала таблицу страниц загоняют в уязвимую строку и заполняют дублированными записями с одинаковым номером фрейма, затем в предсказанное место назначения загоняют вторую таблицу и тоже заполняют. После этого хаммерят соседей, флипают номер фрейма в целевой записи, и второе ядро, обратившись по адресу из первого cuMemMap, дотягивается уже до записей второй таблицы – а через них до произвольного чтения и записи по всей памяти, включая привилегированную память CPU.

Дальше – две ветки, и они бьют по разным конфигурациям хоста. Через тихую порчу от тройного флипа root берётся напрямую: программа не падает, примитив произвольного чтения-записи по памяти держится, и работает это даже с включённым IOMMU – самая жёсткая конфигурация. Через DUE времени меньше – те самые 10 мс, – и годится оно там, где IOMMU выключен, что в Ubuntu не редкость: биты Aperture в заранее разложенной PTE перенаправляют обращение GPU в память CPU, произвольная запись правит структуру учётных данных процесса, euid=0, и это root, который переживает последующий крах ядра. Финальная запись укладывается в миллисекунду. Офлайновая подготовка на A6000 заняла 4 дня, онлайновая часть – меньше двух минут до примитива чтения-записи.

Выбор исследователей опереться на SDC, а не на DUE, инженерно понятен и стоит отдельной оценки. Тихая порча даёт самый сильный сценарий – IOMMU включён, ядро не падает, – но она редка: на банке нашёлся всего один пригодный SDC против 11 DUE, и офлайновый поиск именно тройного флипа растянулся на 4 дня. DUE вдесятеро доступнее, но запирает атаку в 10 мс и в хосты без IOMMU. Они взяли оба: SDC как чистый примитив под сильную конфигурацию, DUE как запасной под слабую. Цена сильного сценария – четверо суток профилирования; на цель, которая того стоит, размен оправдан.

Карту можно вырубить или сдать по гарантии

Даже без повышения привилегий у флипа две мишени. Первая – чужие данные. На карте, которую в облаке шарят по времени, перевёрнутый бит ложится в память соседа: именно так первый GPUHammer год назад молча ронял точность чужой ML-модели, подкручивая её веса. GPUThor делает это на порядки плотнее, а тройной флип, который SECDED пропускает как исправленный, портит расчёт соседа вообще без краха и без следа в счётчиках – тихая диверсия, за которую никто не дёрнется.

Вторая мишень – сама карта. На картах GA10X изоляции сбоев нет, поэтому один DUE валит все процессы на карте, и восстановление требует полного ресета. На A6000 с включённым ECC за сутки хаммеринга набирается 11 DUE – один примерно каждые два часа; на более хрупкой A5000 оценочно один каждые 20 минут. При облачном времени восстановления узла в 0.3 часа это отнимает у карты 13 % доступности – 3.3 часа простоя в сутки, с потерей данных на каждом крахе.

И совсем ехидный вектор – гарантия. У NVIDIA есть политика замены брака (RMA): в каждом банке 8 запасных строк, каждый DUE ремапит одну сбойную строку в запасную, а когда запасные кончаются – больше 8 DUE на банк, – взводится флаг отказа ремаппинга, видимый в nvidia-smi, и карта считается браком, годным к бесплатной замене. Две из четырёх подопытных карт это условие выполнили; на A6000 флаг встал после 9-го DUE, за 18 часов хаммеринга. То есть недобросовестный владелец способен за сутки программно вбить исправную карту в формальный брак и потребовать новую – механизм защиты честного покупателя от дефектного железа превращается в способ доить вендора.

Защита, которую советовали, и мониторинг, который слеп

Сведём к главному счёту. NVIDIA рекомендует включать ECC как основную защиту от GPU-Rowhammer, и в этом – ставка на дешёвую коррекцию: SECDED стоит 6.25 % памяти и до 10 % скорости, ловит двойную ошибку и вроде бы закрывает тему. GPUThor показывает цену этой дешевизны: двойная ошибка оставляет окно в 10 мс, а тройную SECDED вообще пропускает как исправимую. Существуют принципиальные ответы – Per-Row Activation Counting из спецификации DDR5, который убивает класс уязвимости почти целиком, и Refresh Management, уже заложенный в часть GDDR6X. Они дороже по кремнию, но закрывают именно то, что SECDED оставляет нараспашку. Выбор вендора между «дёшево и детектирует» и «дорого и предотвращает» здесь сделан в пользу первого – и статья ровно об этом счёте.

Хуже того, рекомендованный способ заметить атаку тоже дыряв, и авторы это честно называют. Админу советуют следить за активностью ремаппера строк и счётчиком исправленных ошибок. Но ремаппер срабатывает только на DUE и слеп к тихой порче от тройного флипа – той самой, на которой берётся root; а счётчик исправимых ошибок после нескольких тысяч становится недостоверным и практически перестаёт расти. Канал, через который защитнику предложено смотреть, не видит именно того эксплойта, что опаснее всех.

Границы у работы есть, и они названы прямо. Паттерн GPUThor флипает биты на всех проверенных GA10x с GDDR6, но на HBM, GDDR6X и новом поколении GDDR6 не дал ни одного флипа – там другая реализация TRR. Priv-esc с включённым ECC показан на одной карте (A6000), потому что облачные A4000–A5000 не дают включить ECC вовсе. На серверных A100 и новее появляются изоляция сбоев и динамическое отключение страниц: они запирают ошибку в приложении-виновнике, не роняя соседей по карте, и отказной сценарий там слабеет. Но коррекция под ними всё та же SECDED – тихую порчу от тройного флипа она не ловит, и повышение привилегий остаётся в силе. На части Blackwell есть RAS Repair, заменяющий целый канал DRAM после серии отказов ремаппинга: он удлиняет атаку через DUE, но не отменяет её, потому что это лишь надстройка над тем же ремаппингом. А HBM3e и GDDR7 несут ECC на кристалле – видимость ошибок падает, но многобитный флип пробивает и их. Это не «сломали всё», это «сломали конкретный, широко арендуемый класс карт и показали, что рекомендованная защита не защита».

Каждый рубеж обороны сыграл за атакующего

Громкая цифра тут – 23 597 раз, но пугает не она. Пугает то, что каждый слой обороны, встреченный по дороге, у атакующего заработал на атаку. Склейка обращений, придуманная ради пропускной способности, обходится раскладкой по варпам. TRR, гасящий утечку, обходится знанием его же расписания в 72 такта. ECC, который вендор назвал основной защитой, сам роняет четвёртый бит и открывает root. Ремаппер строк, спасающий от дефектов, вооружает поддельный гарантийный брак. А ленивое обслуживание ошибки, сделанное ради скорости, дарит десять миллисекунд, которых хватает на запись euid=0. Это операция высокого класса: не грубая сила, а последовательное превращение чужих защитных решений в собственные примитивы – ровно тем реверсом микроархитектуры, который отделяет исследователя на острие от сборщика эксплойтов по чужим рецептам.

Практический итог холодный. Непривилегированное CUDA-ядро на арендованной видеокарте – самый обыденный объект в облаке – за минуту доходит до root на хосте, и включённый по всем рекомендациям ECC этому не мешает, а местами помогает. NVIDIA получила уведомление 29 апреля 2026 года, вместе с Google, Microsoft и AWS, и попросила подождать с публикацией до 25 августа под свою security-заметку. Настоящая же починка – не ECC, а Per-Row Activation Counting и Refresh Management в кремнии следующих карт; до тех пор общая видеокарта в облаке остаётся тем, чем была всегда для тех, кто умеет слушать её тайминги, – чужой памятью на расстоянии вытянутого варпа. За фактуру спасибо исследователям Университета Торонто.