Процессоры Intel и AMD могут быть атакованы с помощью интересной техники

Исследователи нашли новую технику атаки на процессоры Intel и AMD. Подобные новости появляются регулярно, и каждый раз возникает вопрос: насколько это опасно для обычного пользователя и что делать. Ответ зависит от модели угроз: для домашней машины риск ниже, для публичного сервера — выше.

Разберём, как работают атаки на микроархитектуру, какие меры помогают и как проверить защищённость Linux-системы.

Что такое атака по сторонним каналам

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

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

Насколько это практично

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

Тем не менее игнорировать такие уязвимости нельзя: исследователи показывают, что теоретическая атака может стать практической. Производители выпускают микрокод, а ядро — программные mitigations.

Что делает система

Linux применяет ряд защит: изоляцию таблиц страниц, отключение предсказания ветвлений в отдельных сценариях, ограничение спекулятивного выполнения. Конкретный набор зависит от CPU и версии ядра. Посмотреть статус можно через sysfs.

cat /sys/devices/system/cpu/vulnerabilities/*
lscpu | grep -iE "vulnerability|mitigation"

Для развёрнутой проверки есть скрипт spectre-meltdown-checker. Он показывает, какие уязвимости закрыты, а какие остаются.

sudo apt install spectre-meltdown-checker
sudo spectre-meltdown-checker --no-color | head -50

Обновления

Первое действие — обновить микрокод и ядро. Микрокод исправляет поведение процессора, ядро добавляет программные обходы. Обновляйте оба компонента: только ядро или только прошивка часто недостаточно.

sudo apt update
sudo apt install intel-microcode
# или
sudo apt install amd64-microcode
sudo apt full-upgrade
sudo reboot

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

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

Компромиссы производительности

Защиты стоят производительности: отключаются некоторые оптимизации, растёт время переключения контекста. На серверах с интенсивной сетью и виртуализацией это может быть заметно. Не отключайте mitigations «для скорости», если машина доступна недоверенным пользователям.

# параметры ядра, влияющие на защиты (примеры)
cat /proc/cmdline
# не меняйте их вслепую: сначала прочитайте документацию

Если вы администратор облака, включите планировщик, который изолирует потоки разных арендаторов, и не размещайте контейнеры разных клиентов на одном ядре без необходимости.

Практические меры

• Обновляйте BIOS/UEFI и микрокод.
• Держите ядро актуальным и перезагружайтесь после обновлений.
• Ограничивайте запуск недоверенного кода на критичных хостах.
• Не отключайте SMT, если это не оправдано моделью угроз; но знайте, что SMT расширяет поверхность атаки.
• Изолируйте арендаторов в облаке по физическим ядрам, если данные особо чувствительны.
• Следите за рекомендациями производителей CPU и дистрибутива.

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

Что не поможет

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

И не стоит паниковать из-за каждой новости. Оцените, кто может запускать код на вашей машине и какие данные там находятся. Если ответ «только я и доверенные сервисы», риск существенно ниже, чем в многопользовательском облаке.

Изоляция в облаке и контейнерах

Если на одном хосте работают разные арендаторы, микроархитектурные атаки становятся практичнее. Ограничьте совместное использование ядер: используйте cpuset, отдельные узлы или планировщик, который учитывает изоляцию. В Kubernetes для этого есть topology manager и node affinity, но они не заменяют физическое разделение.

# посмотреть, какие CPU доступны контейнеру
cat /sys/fs/cgroup/cpuset.cpus.effective
nproc
# в Docker можно ограничить набор ядер
docker run --cpuset-cpus="0-3" image

Не запускайте недоверенный код на хостах с секретами. Для CI-раннеров используйте отдельные машины или микроVM. И обновляйте гипервизор: уязвимости в виртуализации могут обходить границы гостевой системы.

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

Итог

Новая техника атаки на Intel и AMD подтверждает, что микроархитектурные уязвимости никуда не исчезли. Обновляйте микрокод и ядро, проверяйте статус mitigations, ограничивайте недоверенный код и учитывайте компромиссы производительности. Для большинства домашних систем этого достаточно; для серверов нужна осознанная политика изоляции.