Meltdown и Spectre - трезво оцениваем риски или безопасность против производительности

  • Автор:

meltdown-spectre-000.pngВ самом начале 2018 года широкую компьютерную общественность буквально огорошили сообщениями о двух серьезных уязвимостях - Meltdown и Spectre. Пожалуй, впервые за всю историю компьютерной индустрии столь серьезная уязвимость оказалась аппаратной и касается практически всех современных процессоров. Ситуацию дополнительно усугубило то, что все доступные варианты устранения последствий данной ошибки ведут к падению производительности, в ином случае значительной. Сейчас, когда вся информационная пена схлынула, настало время трезво разобраться насколько это серьезно и что следует делать.

Почему все так серьезно?

Есть одна известная старая шутка, в которой две новости и обе плохие. В данной ситуации она как никогда уместна. Начнем с того, что обе указанные уязвимости аппаратные, причем связанные не с ошибкой реализации конкретной модели процессора, а с изъянами некоторых положенных в основу современных CPU архитектурных решений. Это означает, что уязвимо все то, что было выпущено в обозримом прошлом, то, что лежит на прилавках и то, что сходит с конвейеров в настоящее время.

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

Коротко о Meltdown

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

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

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

Из процессоров уязвимы только Intel и ARM, продукция AMD данной уязвимости не подвержена.

Коротко о Spectre

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

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

meltdown-spectre-001.png

Насколько все плохо?

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

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

Ну и никто не отменял классического вредоносного ПО, потому что практика показывает, что если пользователь хочет запустить какой-то файл, то он это сделает, несмотря на все уровни защиты системы и наличие в ней антивирусов. Эпидемии шифровальщиков отличное тому подтверждение.

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

Также на сегодняшний день не зафиксировано реального использования данных уязвимостей, что связано с высокой сложностью их реализации и крайне высокими требованиями к квалификации. С одной стороны, хорошо, что условный Джон Смит, Вася Пупкин или Чжан Сань не смогут на коленке собрать троян, ворующие пароли к онлайн-банку, но плохо то, что если такое ПО будет реализовано, то его уровень будет гарантированно высоким.

Исправления и производительность

Так как уязвимость аппаратная, то устранить ее без замены процессора невозможно физически, все существующие патчи устраняют возможность эксплуатации уже обнаруженных уязвимостей программным методом. На сегодняшний день выпущены как обновления микрокода CPU, так и программные заплатки для всех актуальных систем и это, вполне ожидаемо, привело к снижению производительности. Общая оценка снижения: от 10 до 30%.

Intel провела собственные исследования, согласно которым в большинстве задач на системах c SSD и процессорами 8-го поколения (Kaby Lake, Coffee Lake) падение производительности составило около 6%, на более старых процессорах и системах с HDD значение оказалось немного более высоким - около 10%. Однако есть задачи, на которые негативное влияние более существенно:

Тест, который показал наибольшее снижение производительности -- SYSMark 2014 SE Responsiveness. Он показал, что производительность снижается на величину до 21% для рабочих нагрузок, таких как запуск приложений, запуск файлов, просмотр веб-страниц с несколькими вкладками, многозадачность, копирование файлов, шифрование и сжатие файлов, а также установка фонового приложения.

Исполнительный вице-президент Microsoft по Windows Терри Маерсон (Terry Myerson) в официальном блоге привел также различные данные:

На компьютерах под управлением Windows 10 на современных процессорах (относящихся к поколениям 2016 года или более новым, то есть Skylake, Kabylake и более новые), тесты продемонстрируют замедление от силы на единицы процентов, которое подавляющее большинство пользователей не сможет заметить, так как в абсолютных величинах разница будет измеряться миллисекундами.

Компьютеры с Windows 10 на относительно старых процессорах (относящихся к поколениям до 2015 года включительно, Haswell и более старые) в некоторых тестах могут показать более значительное падение производительности, возможно некоторые пользователи смогут его заметить.

Производительность систем под управлением Windows Server на любых процессорах заметно пострадает, особенно на приложениях, интенсивно использующих ввод-вывод, при активации изоляции недоверенного кода.

В Linux ситуация также обстоит не лучшим образом, исследования показывают падение производительности в пределах 5-30%. Довольно подробные исследования провели специалисты RedHat, их результаты во много перекликаются с предыдущими исследованиями:

Наибольшее проседание производительности (8-20%) наблюдается в работе СУБД на нагрузках OLTP, при случайном доступе к прокэшированной памяти, при активном буферизированном вводе/выводе, при большой интенсивности переключения контекста между ядром и пользовательским уровнем (выполнение системных вызовов). Большие потери наблюдаются в тестах tpc, sysbench, pgbench, netperf (до 256 байт) и fio (случайный доступ к памяти NvME).

Падение производительности на 3-7% отмечается при выполнении аналитических запросов в СУБД, в системах поддержки принятия решений (DSS) и в Java VM, в моменты интенсивного обмена информацией по сети или при обращениях к диску.

Снижение производительности на 2-5% наблюдается в решениях HPC (High Performance Computing) при большой вычислительной нагрузке на CPU.

Как видим, менее всего пострадали обычные рабочие станции и домашние ПК, в большинстве задач их пользователи могут совсем не заметить разницы. Для того, чтобы не быть голословными мы провели тестирование своей настольной системы с включенной и выключенной защитой от Meltdown и Spectre. Как и ожидалось, для процессора 4-го поколения i5-4670 (Haswell) потеря производительности составила около 10%.

meltdown-spectre-002.pngПри этом различные показатели производительности системы пострадали примерно равномерно, разве что практически не затронуло работу с ОЗУ.

meltdown-spectre-003.pngПри этом в большинстве повседневных задач такое снижение практически не ощущается, поэтому можно сказать, что большинство пользователей, которые используют ПК для домашних или офисных нужд не должны почувствовать каких-либо ухудшений.

Но этого нельзя сказать про профессиональные применения, на этой же рабочей станции мы обнаружили сильное падение производительности дисковой подсистемы, которая выразилась в сильном увеличении времени отклика и росте очереди при операциях записи большого объема информации (например, при постановке виртуальных машин на паузу) или активном случайном доступе.

Также достаточно сильно страдают операции с СУБД, начиная от внутренней базы 1С и заканчивая PostgreSQL и MS SQL, особенно это заметно на операциях переиндексации и реструктуризации, а также выгрузки-загрузки дампов (где дополнительно сказывается снижение производительности дисковой подсистемы).

Промежуточные выводы

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

Рабочие станции находятся в группе риска, однако он невелик, на текущий момент (осень 2018) нет известного вредоносного ПО, которое бы использовало данные уязвимости. Однако если вы не испытываете проблем с производительностью, то мы бы также не советовали отключать защиту.

А вот на серверах приложений и СУБД, а также в тестовых виртуальных средах защиту будет лучше выключить, риски в данном случае близки к нулю, а производительность страдает значительно, особенно если у вас не самое свежее железо.

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

Включаем / выключаем защиту от Meltdown и Spectre в Windows

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

Для включения отключения защиты следует воспользоваться правкой реестра, официальные рекомендации Microsoft предлагают следующие варианты:

Отключение защиты от Meltdown и Spectre

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Включение защиты от Meltdown и Spectre

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Отключение защиты только от Spectre (актуально для AMD)

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 1 /f

Включение защиты только от Spectre

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 1 /f

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

meltdown-spectre-004.pngЗапутаться в ней решительно негде, если какие-то методы защиты недоступны (не установлены патчи) или неприменимы (защита от Meltdown на AMD), то связанные с ними кнопки будут неактивны. После применения изменений также потребуется перезагрузка.

Включаем / выключаем защиту от Meltdown и Spectre в Linux

Также, как и в Windows описанные ниже методы будут работать только если вы обновили свою систему и установили все необходимые патчи. Ознакомиться с текущим состоянием защиты можно на официальных сатах используемых вами дистрибутивов, например, для Debian или Ubuntu. Если коротко, то изменения сводятся к включению опции Kernel Page Table Isolation (PTI), которая как раз негативно влияет на производительность и пачту от Google - retpoline, влияние которого на систему крайне незначительно.

Прежде всего выясним текущий статус защиты, в системах Debian / Ubuntu для этого можно воспользоваться пакетом spectre-meltdown-checker.

Проще всего владельцам Ubuntu 18.04, для установки пакета им достаточно набрать:

apt-get install spectre-meltdown-checker

В Debian 9 потребуется сначала подключить репозиторий stretch-backports, для этого выполним команду:

add-apt-repository "deb http://ftp.debian.org/debian stretch-backports main"

Затем обновим список пакетов и установим нужный нам пакет с прямым указанием репозитория:

apt-get update
apt-get install -t stretch-backports spectre-meltdown-checker

Для Ubuntu 16.04 и Debian 8 проще всего будет скачать пакет вручную (первая команда сменит текущую директорию на домашнюю):

cd ~
wget http://ftp.ru.debian.org/debian/pool/main/s/spectre-meltdown-checker/spectre-meltdown-checker_0.39-1~bpo9+1_all.deb

И установить его командой:

dpkg -i spectre-meltdown-checker_0.39-1~bpo9+1_all.deb

Теперь запустим проверку, так как выводится достаточно большое количество информации для удобства сразу перенаправим вывод утилите more:

spectre-meltdown-checker | more

На экране вы должны увидеть примерно следующее:

meltdown-spectre-005.pngКак видим, наша система (в данном случае Debian 9.5) защищена от уязвимостей, PTI включен.

Для отключения, негативно влияющего на производительность PTI, необходимо добавить специальную опцию загрузки. Для этого откроем /etc/default/grub и найдем там параметр GRUB_CMDLINE_LINUX_DEFAULT, в кавычках расположены опции данного параметра, в самый их конец, через пробел, добавим nopti, например, в Debian 9 у вас должно получиться:

GRUB_CMDLINE_LINUX_DEFAULT="quiet nopti"

Сохраним файл и обновим загрузчик:

update-grub

Перезагрузимся и вновь запустим проверку:

meltdown-spectre-006a.png

Как видим, система стала уязвима к Meltdown (Variant 3), но осталась защищена от Spectre Variant 1 и 2, потому что для защиты от них используется retpoline, который не вызывает снижения производительности.

Заключение

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

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