Linux disable spectre meltdown

Arch Linux отключить патчи на Meltdown & Co.

Все это время жил без патчей, обновлял систему без обновления ядра.

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

Статья Kernel на Arch Wiki не помогла. Гугл выявляет только следы страха, секьюрити фричество и успокаивающих друг друга голубков.

Единственное что нашел: set kernel boot options:

spectre_v1 тоже можно выключить? Это все что нужно будет прописать в boot options? И где вообще эти kernel boot options?

Или проще поставить старое ядро? У меня сейчас стоит: 14.4.8-1.

Вот тебе весь список параметров для отключения всех заплаток:

И где вообще эти kernel boot options?

Это просто в конце прописать?

Нет. Это нужно прописывать в GRUB_CMDLINE_LINUX_DEFAULT и после этого обновлять конфигураци GRUB:

Понял. Там еще quiet есть:

как я понимаю, вот так?

Да, система работает, если ты это имеешь ввиду.

Если что, проверить с какими параметрами запущено ядро можно так:

Хорошо, понял, буду знать.

И сколько попугаев это экономит на какой-нибудь компиляции ядра?

На глаз +- одинаково. Не знаю, по поводу чего тут ноют. Собирал бледнуюлуну и с заплатками, и без. Время +- 45 мин.

Кибернетизировался и периодически жалуется в lkml на проприетарные импланты.

Не сравнивал. В любом случае, мне эти заплатки на десктопе не нужны, поэтому отключаю.

Нет, он имеет в виду, что ядро Linux версии «14.4.8-1» при сохранении текущей схемы версионирования выйдет примерно через 33 года. Вот он и спрашивает — как там, в будущем? Линус ещё не умер?

Спасибо, теперь дошло : )

плевать на безопасность — скорость важнее! поддался соблазну и тоже отключил, как теперь поймать улучшение производительности? на глаз не заметно, в 7z b никакой разницы, где можно увидеть реальный прирост? а то пугали тормозами — хотелось бы пронаблюдать это! может отключать вовсе и необязательно и заплатки ничего не тормозят?

Разница заметна только на суперкомпьютерах.

да не уже ли? пугали 30% потерей производительности!

и так и этак — нифига быстрее не стало, даже задачи типа

Если не заметно разницы, то зачем шевелится, тем более понижая безопасность в теории?

Не слушай его, делай так:

он в Амстердаме, творческий отпуск. С девочками расслабляется

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

Я отключил эти заплатки сразу после того как они появились. Разница вполне может быть, просто я не сравнивал. Судя по бенчмаркам на phoronix, разница есть, особенно с KPTI.

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

Ну так «у меня десктоп» и сервер бд не очень сочитаются. Также именно десктоп обычно исполняет чужой код (браузер как минимум), а сервер (если твой личный) только доверенный. Так что заплатки и нужнее, и незаметнее как раз на десктопе, указанном в ОП.

при сохранении текущей схемы версионирования

Ты чё куришь? Никакой схемы нет.

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

Зачем? С ними же быстрее работает, да и безопасней как ни крути (тем же веб-браузерам).

Вы все хотите производительность в два раза, совет от создаеля OS 4.0. Выключить журналирование, оно было включено что бы отловить ошибки, щас ошибки отловлены, система пересобрана и нету нужды. Сам я как создатель нуждаюсь в ПК которого нет. Будет вываливаться креш в басибокс стандартная команда fsck -y dev/sda(ваш намек)

Без журнала проседают иопсы и производительность, маня. Причём можешь сразу на минус 3 порядка рассчитывать.

Сам я как создатель нуждаюсь в ПК которого нет.

ПРОХВЕССИОНАЛЫ В ТРЕДЕ.
А ничё, что на ноутах нагрузка на систему охлаждения без патчей увеличивается в простое на 15-20 градусов? НЕТ? Тогда пиши ещё!

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

Опять ты? noblock_validity пробовал?

где ты ПРОХВЕССИОНАЛОВ с ноутбуками видел? все ПРОХВЕССИОНАЛЫ блоками пользуются! но и в блоках есть температурные датчики — сейчас проверю твою теорию и обязательно отпишу.

познавательный файлик, спасибо

где можно увидеть реальный прирост?

На многоядерных процессорах с включенным SMT.

система видит в железе 9 температурных датчиков — не будем вдаваться в подробности что конкретно каждый из них контролирует, факт в том что при отключении патчей температуры не меняются ни в простое ни в нагрузках

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

Давай без «давай». У мен даже тема создана по данному вопросу. Чтобы было для «образованных» понятно: система охлаждения на Thinkpad x260 включалась при 50+ градусов.

Без патчей я мог делать всё, что не относится к нагрузке на intel HD.

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

Дело прошлое, дело решенное. НО ты пиши, пиши.

так у тебя вся доказуха по одному устройству?

система охлаждения на Thinkpad x260 включалась при 50+ градусов

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

а чего тут писать — говно твой тинкпад, впарили тебе барыги лажу, +50 у меня так третьи пни грелись

Я могу запинать и 286ым. Тоже мне, папка. Тебе пишут, что нагружает нехило, а без них — всё норм. Ты мне ещё приведи спектрум.

Ну да ладно, ты прав, я нет. Хули прохвессионалу что-то писать.

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

Источник

Проверка уязвимостей Spectre и Meltdown в Linux

Атаки, такие как Spectre и Meltdown, используют недостаток безопасности во внутреннем программном обеспечении процессора.

Утилита Spectre & Meltdown Checker

Утилита Spectre & Meltdown Checker поддерживает все операционные системы Linux и BSD.

Поддерживаются следующие архитектуры:

• x86 (32 bits)
• amd64/x86_64 (64 bits)
• ARM and ARM64
• На других архитектурах может не работать обнаружение уязвимости mitigations

Установка и запуск:

Утилита MDS Tool

Ранее мы уже писали о данном инструменте:

На странице загрузки скачайте архив MDS Tool для Linux.

Откройте терминал в папке с файлами утилиты и запустите следующим образом:

Как отключить защитные патчи Spectre & Meltdown в Linux

Мы не рекомендуем отключать защиту, но если в угоду производительности или по другим причинам вы хотите отключить защиту, то мы расскажем как это можно сделать.

Прежде чем приступить к отключению патчей, советую прочесть следующую интересную статью:

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

Находим переменную GRUB_CMDLINE_LINUX_DEFAULT=»quiet splash».

При использовании Linux ядер версий 4.14.119+, 4.19.43+, 5.2+ нужно ввести следующее значение: mitigations=off.

При использовании других версий Linux ядер ввести нужно другое значение: pti=off spectre_v2=off nospec_store_bypass_disable.

Затем с помощью комбинации клавиш CTRL+O сохраняем изменения и CTRL+X закрываем редактор.

Обязательно обновляем Grub:

Результат проверки на наличие уязвимостей Spectre и Meltdown после отключения защитных патчей.

Источник

Disable Spectre and Meltdown mitigations

Can I disable Spectre and Meltdown mitigation features in Ubuntu 18.04LTS?

I want to test how much more performance I gain when I disable these two features in Linux, and if the performance is big, to make it permanently.

3 Answers 3

A number of kernel boot parameters are available to disable or fine-tune hardware vulnerability mitigations:

• for Spectre v1 and v2: nospectre_v1 (x86, PowerPC), nospectre_v2 (x86, PowerPC, S/390, ARM64), spectre_v2_user=off (x86)
• for SSB: spec_store_bypass_disable=off (x86, PowerPC), ssbd=force-off (ARM64)
• for L1TF: l1tf=off (x86)
• for MDS: mds=off (x86)
• for TAA: tsx_async_abort=off
• for iTLB multihit: nx_huge_pages=off
• KPTI can be disabled with nopti (x86, PowerPC) or kpti=0 (ARM64)
• TSX async abort: tsx_async_abort=off (x86)
• KVM NX huge pages: kvm.nx_huge_pages=off (x86)

A meta-parameter, mitigations , was introduced in 5.2 and back-ported to 5.1.2, 5.0.16, and 4.19.43 (and perhaps others). It can be used to control all mitigations, on all architectures, as follows:

• mitigations=off will disable all optional CPU mitigations;
• mitigations=auto (the default setting) will mitigate all known CPU vulnerabilities, but leave SMT enabled (if it is already);
• mitigations=auto,nosmt will mitigate all known CPU vulnerabilities and disable SMT if appropriate.

Some of these can be toggled at runtime; see the linked documentation for details.

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

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

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

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

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

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

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

Коротко о Meltdown

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

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

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

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

Коротко о Spectre

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

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

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

На первый взгляд может показаться, что все пропало и все мы находимся в списке потенциальных жертв. Но, если взглянуть на проблему трезво, то станет ясно, что 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 на относительно старых процессорах (относящихся к поколениям до 2015 года включительно, Haswell и более старые) в некоторых тестах могут показать более значительное падение производительности, возможно некоторые пользователи смогут его заметить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник