Високопродуктивні графічні процесори давно стали основою інфраструктури штучного інтелекту, криптографії та HPC, однак нові академічні дослідження демонструють, що GPU можуть стати і точкою входу для повного захоплення хост-системи. Серія робіт під назвами GPUBreach, GDDRHammer та GeForge показала практичні RowHammer-атаки на пам’ять GDDR6, здатні зруйнувати ізоляцію між процесами, обійти апаратний захист і призвести до ескалації привілеїв до рівня root.
RowHammer у відеопам’яті GDDR6: чому GPU стали новою ціллю
RowHammer — це клас вразливостей DRAM, коли інтенсивне багаторазове зчитування однієї рядки пам’яті (hammering) викликає електричні перешкоди та bit-flip у сусідніх рядках. Унаслідок цього змінюються значення бітів у комірках, до яких процес формально не має доступу, що безпосередньо підриває базовий принцип ізоляції пам’яті.
Довгий час вважалося, що сучасні GPU з пам’яттю GDDR6, розширеними механізмами оновлення рядків та, за потреби, ECC, малопридатні для реальних RowHammer-експлойтів. Проривом стала робота GPUHammer (2025 рік), де вперше описано практичну реалізацію RowHammer-атаки на GPU NVIDIA: за рахунок масового паралельного «молотіння» вдалося спричинити цілеспрямовані помилки в GDDR6 і знизити точність моделей машинного навчання на GPU до 80%.
Нові атаки GPUBreach, GDDRHammer та GeForge розвивають цю ідею далі: вони вже орієнтовані не лише на порушення цілісності обчислень, а на компрометацію таблиць сторінок GPU, доступ до пам’яті хоста та, у випадку GPUBreach, — на повну CPU-ескалацію привілеїв.
GPUBreach: від пошкодження таблиць сторінок GPU до root-доступу
Маніпуляція PTE та захоплення пам’яті відеокарти
У дослідженні GPUBreach показано, що спрямовані bit-flip у GDDR6 дають змогу змінювати критичні структури керування пам’яттю GPU, насамперед записи таблиць сторінок (page table entries, PTE). Саме PTE задають, які ділянки відеопам’яті доступні конкретному контексту або ядру CUDA.
Після успішної атаки низькопривілейований процес отримує довільний доступ на читання та запис до пам’яті GPU. Модифікуючи окремі біти у PTE, зловмисник може перенаправляти сторінки на потрібні йому фізичні області пам’яті, розширюючи власні права далеко за межі виділеного буфера.
Обхід IOMMU і атаки через DMA на оперативну пам’ять CPU
Найбільш критичний аспект GPUBreach — можливість атаки навіть при увімкненому IOMMU, який має ізолювати пристрої вводу/виводу від оперативної пам’яті та блокувати зловмисні DMA-операції. Дослідники демонструють, що після пошкодження PTE GPU може виконувати DMA-доступ до тих регіонів оперативної пам’яті хоста, які формально дозволені політиками IOMMU, наприклад до буферів драйвера NVIDIA.
Після цього стає можливим пошкодження довіреного стану драйвера та створення умов для помилок керування пам’яттю в ядрі ОС. Отримавши примітив довільного запису в адресному просторі ядра, атакуючий переходить до повної ескалації привілеїв до root і може запускати команди з правами ядра, фактично повністю захопивши систему.
Крадіжка криптографічних ключів і саботаж моделей ШІ
Окрім захоплення привілеїв, GPUBreach дає змогу екфільтрувати чутливі дані з відеопам’яті. Дослідження демонструє можливість викрадення криптографічних ключів, зокрема з бібліотеки NVIDIA cuPQC, а також точкове спотворення ваг моделей машинного навчання, що працюють на GPU.
Таким чином, одна й та сама RowHammer-атака на GPU одночасно загрожує конфіденційності (витік ключів та даних), цілісності (маніпуляція моделями ШІ) та доступності сервісів (зрив коректної роботи прискорювачів).
GDDRHammer та GeForge: інші сценарії RowHammer-атак на GPU
У роботі GDDRHammer атакуючі спрямовують RowHammer на поле aperture у записах таблиць сторінок GPU. Це дозволяє непривілейованому CUDA-ядру читати й змінювати всю оперативну пам’ять CPU, доступну через GPU. Основний акцент тут — максимальне розширення доступу до пам’яті хоста, без обов’язкової побудови повного ланцюга до root-експлойту ядра.
Атака GeForge фокусується на компрометації останнього рівня каталогу сторінок (page directory, PD0). Підміна трансляцій адрес на цьому рівні теж відкриває шлях до довільного доступу до пам’яті GPU та хоста. Водночас її ключове обмеження — необхідність вимкненого IOMMU, що знижує практичну небезпеку в сучасних захищених інфраструктурах.
У цьому контексті GPUBreach вирізняється як найбільш небезпечний сценарій: він працює при активному IOMMU, дає повноцінну CPU-ескалацію привілеїв і поєднує витік секретів, саботаж ШІ та захоплення системи в одному векторі атаки.
Наслідки для хмарних ІІ-платформ, дата-центрів і HPC
Насамперед під загрозою опиняються хмарні ІІ-сервіси, багатокористувацькі GPU-платформи та HPC-кластери, де один фізичний прискорювач поділяють кілька клієнтів. За такого сценарію успішна RowHammer-атака на GPU дозволяє потенційно:
• зчитувати та модифікувати моделі й дані інших орендарів, розміщених на тому самому GPU;
• отримувати доступ до пам’яті хоста, де можуть зберігатися облікові дані, ключі шифрування чи секрети керуючих вузлів;
• розширювати атаку на всю інфраструктуру, включно з системами оркестрації контейнерів, керування чергами задач і вузлами зберігання.
Для провайдерів хмарних сервісів це означає, що GPU більше не можна вважати «прозорим» акселератором. Вони мають розглядатися як повноцінні, потенційно ворожі учасники моделі загроз із власним простором пам’яті, драйверами та складною логікою доступу до системних ресурсів.
Захист GPU від RowHammer: поточні можливості та обмеження
Очевидний перший крок — активація ECC на GPU там, де це можливо. Однак попередні дослідження RowHammer, зокрема ECCploit та ECC.fail, переконливо показали, що ECC не є універсальним щитом: при індукції кількох помилок у межах одного слова пам’яті стандартні схеми корекції або не спрацьовують, або можуть призводити до «тихої» корупції даних.
На десктопних і мобільних відеокартах, де ECC зазвичай відсутній, сьогодні не існує надійних, загальновизнаних механізмів повного захисту від RowHammer на апаратному рівні. Для дата-центрів і хмарних провайдерів доцільно комбінувати декілька підходів:
• мінімізувати спільне використання одного GPU різними орендарями та впроваджувати жорсткішу сегментацію задач;
• забезпечити оперативне оновлення драйверів GPU та мікропрограм, швидко застосовуючи патчі від вендора;
• впроваджувати моніторинг аномальних патернів доступу до пам’яті (часте «молотіння» тих самих рядків);
• додатково перевіряти цілісність критичних структур, зокрема таблиць сторінок GPU, засобами як ПЗ, так і апаратних механізмів.
Нові RowHammer-атаки на GPU наочно показують, що безпека апаратних прискорювачів має стати невід’ємною частиною стратегії кіберзахисту організацій. Компаніям, які покладаються на GPU для ШІ, криптографії та високопродуктивних обчислень, варто вже зараз переглянути власні моделі загроз, оновити політики сегментації ресурсів і вимагати від вендорів рішень, усталених до маніпуляцій з відеопам’яттю. Чим раніше ці ризики буде враховано при проєктуванні інфраструктури, тим менша ймовірність, що наступне покоління атак перетворить GPU з інструмента прискорення на головну точку входу для повного компрометації системи.
