Текущая уязвимость процессора Meltdown Intel в настоящее время исправлена путем включения изоляции таблицы страниц. Возникает вопрос, как это отключить: как отключить изоляцию таблиц страниц, чтобы восстановить потерю производительности из-за дыры в защите процессора Intel?
Мой вопрос противоположен: есть ли способ проверить в работающей системе, эффективен ли механизм PTI в системе и, таким образом, система защищена? Я специально ищу cat /proc/something
или cat /sys/something
не проверяю версию ядра или параметр конфигурации или тому подобное.
Отключение CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, как предложил Раниц, не помогает в настольной Ubuntu, но может помочь в облачных экземплярах:
Вы можете проверить,
/proc/cpuinfo
как предложил JonasCz :Или из
dmesg
(спасибо Джейсону Крейтону ):Вы можете скомпилировать тестовую программу из Raphael Carvalho для обнаружения Meltdown:
в исправленной системе это должно заканчиваться выводом
Проверьте с помощью инструмента из https://github.com/speed47/spectre-meltdown-checker :
На исправленной системе должно отображаться следующее:
Не устанавливайте 4.4.0-108-generic на Xenial! Это нарушает функциональность загрузки / перезагрузки / выключения / приостановки !
Установите 4.4.0-109-generic ( подробности см. В USN-3522-3 )!
Как уже писал Роби Басак , в Ubuntu есть страница о статусе уязвимостей Spectre и Meltdown .
Также есть:
источник
dmesg | grep isolation && echo "patched :)" || echo "unpatched :("
перечисленная команда неоправданно опасна : она не показывает, какая строка была на самом деле сопоставлена, а также с радостью напечатала бы «исправлено :)», если был найден случайный другой экземпляр «изоляции» .../proc/cpuinfo
для cpu_insecure). Если вы поместите это в сценарий, и в будущем у вас будет процессор, где проблема будет устранена в его микроархитектуре,/proc/cpuinfo
он больше не скажет,cpu_insecure
и ваш сценарий будет считать, что ядро не исправлено, даже если оно исправлено . Я также рекомендовал бы против третьего предложения, так как слишком вероятно, что в какой-то моментisolation
вdmesg
выводе может быть слово без ссылки на изоляцию таблицы страниц ядра.isolation
будет соответствовать какKernel/User page tables isolation: enabled
иKernel/User page tables isolation: disabled on command line
.Запустите следующую команду:
Если он отображается включенным, то PTI включен. Если ничего не отображается или вы видите «отключен» в терминале, то PTI отключен. Ubuntu еще не опубликовал патч, поэтому он не будет отображать никаких сообщений.
источник
dmesg
вывода. Посмотрите,/var/log/kern.log*
идет ли он достаточно далеко, чтобы получить загрузочные сообщения. Ubuntu раньше записывалdmesg
выходные данные во время загрузки/var/log/dmesg
, но, похоже, больше этого не делает.dmesg: invalid option -- 'w'
.-H
также недействителен. Снятие флагов для меня работало нормально, так как в этом ответеВы можете проверить
cat /proc/cpuinfo
, если он сообщает вcpu_insecure
разделе «ошибки», то PTI включен.Если оно пустое (или просто не
cpu_insecure
отображается в списке ), то, скорее всего, вы используете ядро, которое еще не было исправлено (Ubuntu не имеет), или у вас есть процессор AMD (для которого это, вероятно, не будет включено, так как они не уязвимы).В настоящее время все процессоры считаются уязвимыми в последнем ядре 4.15.
источник
cpu_insecure
для любого процессора x86; 4.14.12 и новее будут устанавливать его только для процессоров Intel (включая слишком старые или слишком примитивные, чтобы быть уязвимыми. Оба будут устанавливать его, даже если KPTI отключен.Я нашел этот отличный сценарий sh для проверки уязвимостей Meltdown / Spectre в вашей системе:
https://github.com/speed47/spectre-meltdown-checker
Сценарий проверяет вашу систему на наличие известных исправлений Meltdown и Spectre в вашей системе, чтобы сообщить вам, устранены ли эти уязвимости вашей ОС.
источник
Вы можете проверить /proc/config.gz для
CONFIG_PAGE_TABLE_ISOLATION=y
это означает , что ядро скомпилировано с КПТИ.Это на моей исправленной системе Arch Linux под управлением 4.14.11-1:
источник
/proc/
не включена по умолчанию в ядрах Ubuntu. Вместо/boot/config-$( uname -r )
этого (гораздо менее элегантный) обходной путьНа моем экземпляре AWS Ubuntu 14.04.5 LTS EC2 я запустил
Следует сказать:
Для обновления я сделал:
Я думаю, что это тоже нормально:
Чтобы проверить версию ядра:
Должен быть 3.13.0-139-родовым или более новым.
источник