22/09/25
Как пишет Securitylab, уязвимость позволяет виртуальной машине договориться с процессором так, чтобы в кэш L1 попали произвольные байты оперативной памяти хоста, а затем извлечь их через так называемый тайминг-канал, что даёт атакующему примитив произвольного чтения памяти хоста и возможность украсть секреты соседних гостевых систем.
Чтобы понять, как это работает, достаточно вспомнить два свойства современных x86-CPU: спекулятивное выполнение и иерархические SRAM-кэши. Процессор заранее выполняет инструкции по прогнозу ветвления, и хотя результаты спекулятивных вычислений обычно откатываются, побочные эффекты в кэше остаются. Эксплойт комбинирует «half-Spectre»-приём — когда код ядра по ошибке спекулятивно загружает в L1 данные по контролируемому индексу — и «L1 Terminal Fault» (L1TF), аппаратную ошибку трансляции адреса, при которой процессор при ошибке трансляции всё же может обратиться к L1 так, словно адрес был физическим. В сумме это позволяет загрузить в L1 нужный байт памяти и затем закодировать его в виде выбора строки в буфере атакующего, а потом восстановить значение по измерению времени доступа (Flush+Reload).
VUSec показали, что на практике эта связка даёт гораздо больше, чем утечку отдельных байтов: атакующий гость сначала «пересекает» указатели в структуре physmap ядра хоста и восстанавливает базу отображения физической памяти, затем идёт по цепочке указателей — от объектов KVM к task_struct и корневым таблицам страниц — и в итоге способен проводить «поразмерную» расшифровку таблиц страниц. Это позволяет переводить гостевые виртуальные адреса в физические адреса хоста и массово считывать чужую память, вплоть до приватных ключей TLS в примере с Nginx.
К счастью, не все процессоры уязвимы — более современные модели Intel (Cascade Lake и новее) не подвержены L1TF. Для уязвимых Skylake-классов потребовался программный ответ, причём набор мер оказался многоуровневым и трудоёмким. В числе применённых шагов — тщательный поиск и исправление «half-Spectre»-гаджетов в коде KVM и ядре (использование array_index_nospec и подобных техник), принудительная очистка кэша L1 при переходах VM Exit/Enter, и более фундаментальное решение от Google — Address Space Isolation (ASI).
ASI разработана как проактивная архитектурная защита: ядро работает в «ограничённом» адресном пространстве без чувствительных отображений, а при необходимости доступа в полное пространство происходит контролируемый ASI-Exit с очисткой микропамяти процессора и с последующим ASI-Enter. Это разрывает связь между спекулятивным выполнением в контексте ядра и секретными данными пользователей и гостей. По опыту Google, при включённом ASI и очистке L1-кэша на входимых переходах общая деградация производительности в бенчмарках оказалась невысокой — обычно меньше 1–3%.
Ещё одна непростая деталь — разделяемые ресурсы гиперпотока (SMT). Даже после очистки кэша остаётся риск, что соседний гиперпоток успеет прочесть данные до очистки, поэтому Google реализовала механики «stunning» — временной паузы соседнего гиперпотока при ASI-Exit, чтобы исключить утечки, хотя это требует аккуратной оптимизации, чтобы минимизировать накладные расходы на производительность.
Отдельно авторы отмечают важность совместной работы индустрии и науки. Группа VUSec проводила исследование на выделённом узле, предоставленном Google, чтобы не подвергать риску других клиентов; позже учёные представили результаты в офисе Google в Цюрихе и получили вознаграждение в $151 515 — самый высокий уровень по программе вознаграждений Google Cloud VRP. Исправления и патчи в части KVM и ядра были доведены до Linux-сообщества, а ASI развивается совместно с upstream.
Вывод прост: «лечить» по одному гаджету после каждой новой аппаратной атаки ненадёжно и затратнее в долгосрочной перспективе, чем архитектурные контрмеры, которые разрывают фундаментальную возможность спекулятивных утечек. Address Space Isolation — пример такого подхода: он закрывает целый класс атак, оставаясь при этом приемлем по производительности, что критично для широкого распространения и реальной безопасности облачных сред.
