Чипы Intel и AMD уязвимы для новой атаки Retbleed

Retbleed — исследовательская атака, которая использует инструкции возврата в процессорах Intel и AMD для утечки данных через спекулятивное выполнение. Она относится к семейству атак по сторонним каналам и показывает, что микроархитектурные оптимизации продолжают создавать новые классы уязвимостей.

Разберём, как работает Retbleed, какие меры уже включены в Linux и что делать пользователю.

Как работает атака

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

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

Кого затрагивает

Уязвимость касается определённых поколений Intel и AMD. Производители выпустили микрокод, а ядро Linux добавило программные обходы. Конкретный статус зависит от модели CPU и версии прошивки, поэтому проверяйте свою систему, а не полагайтесь на общие списки.

lscpu | grep -E "Model name|Vendor ID|Family|Model"
cat /sys/devices/system/cpu/vulnerabilities/retbleed

Если в файле указано Not affected, защита не требуется. Если Vulnerable — нужны обновления. Промежуточные статусы описывают включённые меры.

Обновление

Обновите микрокод и ядро. В Debian/Ubuntu пакеты называются intel-microcode и amd64-microcode; в Fedora — microcode_ctl. После установки нужна перезагрузка.

sudo apt update
sudo apt install intel-microcode
sudo apt full-upgrade
sudo reboot

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

dmesg | grep -i microcode
journalctl -k -b | grep -i retbleed

Не устанавливайте микрокод из случайных источников: подписанный пакет дистрибутива безопаснее архива с форума.

Стоимость защиты

Обходы Retbleed могут снижать производительность, особенно в задачах с большим числом вызовов функций: базы данных, виртуализация, сетевые сервисы. В некоторых сценариях падение заметно, в других — почти нет.

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

cat /proc/cmdline
# примеры параметров (не применяйте вслепую)
# retbleed=auto / retbleed=off

Отключение защиты повышает производительность, но возвращает уязвимость. Для публичного сервера это плохой компромисс; для изолированной тестовой машины — допустимо, если вы понимаете последствия.

Проверка производительности

Сравнивайте не «на глаз», а на реальной нагрузке. Возьмите бенчмарк, близкий к вашему сценарию: компиляция, база данных, веб-запросы, шифрование.

# пример: время сборки
time make -j$(nproc)
# пример: пропускная способность диска
fio --name=randread --rw=randread --bs=4k --iodepth=32 --runtime=60 --time_based
# пример: HTTP-нагрузка
wrk -t4 -c100 -d30s http://localhost:8080/

Замеряйте до и после обновления на одинаковой конфигурации. Учитывайте прогрев и фоновые задачи, иначе разница будет случайной.

Виртуализация и облако

Если вы размещаете контейнеры разных арендаторов на одном хосте, изоляция ядер важнее скорости. Используйте cpuset, отдельные узлы или планировщик с учётом топологии. Для критичных данных выбирайте выделенные инстансы.

cat /sys/fs/cgroup/cpuset.cpus.effective
docker run --cpuset-cpus="0-3" image

Проверьте, что гипервизор обновлён: уязвимости в виртуализации могут обходить границы гостевой системы.

Что делать домашнему пользователю

Обновите систему и перезагрузитесь. Не отключайте защиты ради нескольких процентов производительности. Если компьютер используется только вами и вы не запускаете недоверенный код, практический риск ниже, но обновления всё равно нужны.

Для браузера включите изоляцию сайтов и не отключайте песочницу. Для серверов ограничьте доступ и следите за обновлениями ядра.

uname -r
cat /sys/devices/system/cpu/vulnerabilities/*

Как проверить, что защиты действительно включены

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

uname -r
cat /sys/devices/system/cpu/vulnerabilities/retbleed
journalctl -k -b | grep -iE "microcode|retbleed" | head -20
dmesg | grep -i "smpboot" | head -5

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

Для парка машин соберите версии ядра и статусы в один отчёт. Это занимает минуту, но сразу показывает узлы, которые «обновились» формально и остались уязвимыми фактически.

for h in $(cat hosts.txt); do
  ssh "$h" 'printf "%s %s " "$(hostname)" "$(uname -r)"; cat /sys/devices/system/cpu/vulnerabilities/retbleed'
done

Что делать, если обновление ломает нагрузку

Обходы Retbleed влияют на ветвления и возвраты, поэтому сильнее всего страдают базы данных, интерпретаторы и виртуализация. Если после обновления вы видите падение пропускной способности, не отключайте защиту сразу: сначала измерьте, где именно теряется время.

perf stat -a sleep 10
perf top
pidstat -u -w 1 10
vmstat 1 10

Часто оказывается, что узкое место не в CPU, а в диске или сети, и обновление просто совпало с другим изменением. Сравните графики до и после, а не один замер. Если регрессия подтверждена, проверьте, нет ли более новой версии ядра с оптимизированными обходами.

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

Итог

Retbleed — ещё одно напоминание, что микроархитектурные атаки не исчезли. Обновляйте микрокод и ядро, проверяйте статус уязвимостей, оценивайте производительность на реальной нагрузке и не отключайте защиты без веской причины. Для большинства пользователей регулярные обновления остаются достаточной мерой.