LINUX.ORG.RU

В процессорах Loongson для Linux-систем обнаружили аппаратную утечку данных из L1-кеша

 , ,

В процессорах Loongson для Linux-систем обнаружили аппаратную утечку данных из L1-кеша

1

1

Исследователи из немецкого Центра информационной безопасности имени Гельмгольца CISPA представили на конференции USENIX Security 2026 аппаратную уязвимость LoongLeak, обнаруженную в китайских процессорах Loongson 3A5000 и Loongson 3A6000. Непривилегированная программа может использовать её для извлечения оставшихся в кеше первого уровня данных других процессов, ядра операционной системы и гипервизора. Атака также возможна из контейнера или гостевой виртуальной машины.

Практическое значение уязвимости связано прежде всего с Linux и другим свободным ПО. Для LoongArch существует отдельный порт в основном ядре Linux, а Debian уже включил loong64 в число официальных архитектур с планом выпуска в составе Debian 14. Поддержку архитектуры также развивают другие Linux-дистрибутивы и проекты открытого системного ПО.

Официальной версии Windows для LoongArch при этом нет. В перечнях поддерживаемых Microsoft процессоров для Windows 11 фигурируют решения AMD, Intel и Qualcomm, а установочные образы операционной системы выпускаются отдельно для x64 (microsoft.com) и Arm64. Поэтому компьютеры и серверы на Loongson на практике ориентированы прежде всего на Linux и открытый программный стек. Сама LoongArch, однако, является собственной архитектурой Loongson, поэтому речь идёт именно об открытости используемых операционных систем и программного окружения, а не о полной открытости процессора по модели RISC-V.

LoongLeak связана с особенностями выполнения инструкции FLD.S. В соответствии с руководством по архитектуре LoongArch она загружает из памяти 32-разрядное значение в 64-разрядный регистр с плавающей точкой, оставляя его старшие 32 бита в «неопределённом» состоянии. При использовании 256-разрядного векторного расширения LASX неопределёнными оказываются уже 224 бита, или 28 байт.

Исследователи установили, что в этих разрядах могут появляться не случайные значения, а данные, оставшиеся после предыдущих операций в кеше L1D. Атакующий способен подготовить внутреннее состояние процессора и выбирать нужный набор кеша, смещение внутри кеш-линии и один из её путей. Полученная информация непосредственно попадает в архитектурно доступные регистры.

Этим LoongLeak отличается от Spectre, Meltdown и большинства классических атак по сторонним каналам. Для извлечения информации не требуются спекулятивное выполнение, высокоточный таймер или анализ задержек обращения к памяти. Авторы работы классифицируют LoongLeak как архитектурную ошибку: процессор возвращает посторонние данные в результате штатного выполнения инструкции.

В лабораторных условиях средняя скорость извлечения информации достигла 315,8 Мбайт/с, а необработанный поток данных — 483,3 Мбайт/с. В более реалистичных сценариях, требующих переключения процессов или виртуальных машин, скорость снизилась до 6,2 и 4,5 Мбайт/с соответственно. Для проведения атаки злоумышленнику необходимо запустить непривилегированный нативный код на уязвимой системе, причём атакующий и жертва должны последовательно или одновременно выполняться на одном физическом ядре.

Для демонстрации последствий исследователи извлекли из памяти ядра Linux полный 512-разрядный мастер-ключ тома, зашифрованного при помощи LUKS и AES-XTS. В другом эксперименте с Loongson 3A6000 через общий для двух SMT-потоков кеш удалось получить первые 32 байта записи пользователя root из /etc/shadow, включая полную соль и девять байт хеша пароля.

LoongLeak также позволила получить значения ASLR и stack canary, используемые для усложнения эксплуатации ошибок памяти. Кроме того, исследователи продемонстрировали возможность пересечения границ виртуализации: код внутри гостевой системы способен извлекать данные другой виртуальной машины или самого гипервизора. Это делает проблему особенно существенной для многопользовательских серверов, облачных платформ и систем виртуализации на базе Linux и KVM.

Полностью исправить уязвимые процессоры обновлением Linux, микрокода или другого программного обеспечения нельзя, поскольку первопричина находится в аппаратной реализации. В качестве временной защиты предлагается вытеснять содержимое L1D-кеша несекретными данными при переходе из ядра в пользовательское пространство. В тестах исследователей максимальное замедление от такой меры составило 1,4%, а в большинстве тестов падение производительности не превышало 0,1%.

На Loongson 3A6000 дополнительно необходимо отключить один логический поток каждого физического ядра, фактически отказавшись от SMT. Другой вариант — перехватывать и программно эмулировать инструкции с плавающей точкой, LSX и LASX, однако в тестах с интенсивным использованием плавающей арифметики это приводило к замедлению в 10–21 раз.

Исследователи сообщили Loongson об уязвимости 23 июля 2025 года. Компания воспроизвела проблему и попросила сохранить сведения о ней в тайне на один год. Впоследствии производитель устранил утечку в новой аппаратной ревизии Loongson 3A6000. Владельцам ранее выпущенных 3A5000 и 3A6000 остаётся использовать программные меры снижения риска либо заменить процессор. Специальных средств, позволяющих обнаружить уже проводившуюся атаку LoongLeak, пока нет.

>>> Источник

★★★★★

Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 1)
Ответ на: комментарий от firkax

Нет, они не «знали про багу», они считали это фичей и сделали специально, см. выше.

Так я и посмотрел выше, где вы пишете, что это они о производительности думали. Нет, производительность тут не при чём: доп такт для зануления не нужен.

anonmyous ★★★
()
Ответ на: комментарий от firkax

Скорее всего причина была именно в этом, и там действительно вообще не подумали о том, что отдавать мусор из левого кеша - это утечка данных.

То есть, у них нет ни здравого смысла, ни желания ознакомиться с аналогичными проблемами, типа espfix/espfix64? Крайне странная теория, всё же проц не дворники клепают.

anonmyous ★★★
()
Ответ на: комментарий от firkax

так у них данные с прошлой операции в защелках висели и инструкция их читала. защелки прямо в кэше, потому что массив регистров Nх64бит обладает поганой особенностью. даже двумя.

  1. во-первых емкость подключенных транзисторов к линии - N штук. очень быстро сбрасывают скорость.

  2. во-вторых, они текут. Ion/Ioff ~ 100, и падает с уменьшением техпроцесса. Поэтому для N=128 и 90nm уже ток всех закрытых транзисторов больше тока открытого.

поэтому большие SRAM рубят на мелкие блоки, по 16-32 элемента. и их данные защелкивают прямо где-то рядом с этими блоками. а из защелок уже выбирают то что надо. можно даже на двойной частоте.

вот из этих защелок и потекло.

ckotctvo
()
Ответ на: комментарий от anonmyous

Это не espfix. Там была ошибка уровня микрокода. Вернее даже не так: в х86 при 32битной записи в 64битный регистр верхние 32бита нулятся, а при записи 16бит в 32битный - нет. Надо было нулить их и писать 16 бит. Вообще кстати непонятно, почему IRET так себя вел - ну похерь на стэке лишние биты в ноль и retайся.

А тут прям четко схалявили. Они походу решили в экономию энергии поиграть: инструкция читает данные из одного банка где проблем нет. Там 2 этапа, поскольку физически нельзя в один шаг прочитать из большого SRAM-файла. Я чуть выше расписал отчего так. Походу первую стадию они подавили по всем неактивным банкам кэша.

Но вторая стадия выборки срабатывает по всем остальным банкам кэша и читает данные от предыдущих команд.

ckotctvo
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.