Как проверить, что KPTI включен на моем Ubuntu?

64

Текущая уязвимость процессора Meltdown Intel в настоящее время исправлена ​​путем включения изоляции таблицы страниц. Возникает вопрос, как это отключить: как отключить изоляцию таблиц страниц, чтобы восстановить потерю производительности из-за дыры в защите процессора Intel?

Мой вопрос противоположен: есть ли способ проверить в работающей системе, эффективен ли механизм PTI в системе и, таким образом, система защищена? Я специально ищу cat /proc/somethingили cat /sys/somethingне проверяю версию ядра или параметр конфигурации или тому подобное.

Мартин Высний
источник

Ответы:

4

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

$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion
Mitigation: Clear CPU buffers; SMT vulnerable
Mitigation: PTI
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: usercopy/swapgs barriers and __user pointer sanitization
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
Михал Пжибылович
источник
Потрясающий ответ - кратко и точно. Спасибо.
Мартин Высный
63
  • Отключение CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, как предложил Раниц, не помогает в настольной Ubuntu, но может помочь в облачных экземплярах:

    grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \
    echo "patched :)" || echo "unpatched :("
    

  • Вы можете проверить, /proc/cpuinfoкак предложил JonasCz :

    grep -q "cpu_insecure\|cpu_meltdown\|kaiser" /proc/cpuinfo && echo "patched :)" \
    || echo "unpatched :("
    

  • Или из dmesg(спасибо Джейсону Крейтону ):

    dmesg | grep -q "Kernel/User page tables isolation: enabled" \
    && echo "patched :)" || echo "unpatched :("
    

  • Вы можете скомпилировать тестовую программу из Raphael Carvalho для обнаружения Meltdown:

    sudo apt-get install git build-essential
    cd /tmp
    git clone https://github.com/raphaelsc/Am-I-affected-by-Meltdown.git
    cd Am-I-affected-by-Meltdown
    make
    sudo sh -c "echo 0  > /proc/sys/kernel/kptr_restrict"
    ./meltdown-checker
    

в исправленной системе это должно заканчиваться выводом

...
so far so good (i.e. meltdown safe) ...

System not affected (take it with a grain of salt though as false negative
may be reported for specific environments; Please consider running it once again).

  • Проверьте с помощью инструмента из https://github.com/speed47/spectre-meltdown-checker :

    cd /tmp
    wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh
    sudo sh /tmp/spectre-meltdown-checker.sh
    

На исправленной системе должно отображаться следующее:

Spectre and Meltdown mitigation detection tool v0.27

Checking for vulnerabilities against live running kernel Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64
...
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  YES 
* PTI enabled and active:  YES 
> STATUS:  NOT VULNERABLE  (PTI mitigates the vulnerability)

Не устанавливайте 4.4.0-108-generic на Xenial! Это нарушает функциональность загрузки / перезагрузки / выключения / приостановки !

Установите 4.4.0-109-generic ( подробности см. В USN-3522-3 )!


Как уже писал Роби Басак , в Ubuntu есть страница о статусе уязвимостей Spectre и Meltdown .

Также есть:

N0rbert
источник
3
Обновления для Ubuntu запланированы на 9 января. Они могут приземлиться раньше, но я бы на это не рассчитывал. insights.ubuntu.com/2018/01/04/…
Ранис
4
IMO, предпочтительнее ответы типа «dmesg | grep изоляция». Некоторые дистрибутивы (по крайней мере, Debian Stretch, может быть, другие) портировали PTI на старое ядро, но не флаг cpu_insecure в / proc / cpuinfo. В этих системах поиск в журнале dmesg - единственный способ проверить, AFAICT.
Джейсон Крейтон
3
Я думаю, что dmesg | grep isolation && echo "patched :)" || echo "unpatched :("перечисленная команда неоправданно опасна : она не показывает, какая строка была на самом деле сопоставлена, а также с радостью напечатала бы «исправлено :)», если был найден случайный другой экземпляр «изоляции» ...
Jaap Eldering
2
Я бы рекомендовал против второго предложения (grep /proc/cpuinfoдля cpu_insecure). Если вы поместите это в сценарий, и в будущем у вас будет процессор, где проблема будет устранена в его микроархитектуре, /proc/cpuinfoон больше не скажет, cpu_insecureи ваш сценарий будет считать, что ядро не исправлено, даже если оно исправлено . Я также рекомендовал бы против третьего предложения, так как слишком вероятно, что в какой-то момент isolationв dmesgвыводе может быть слово без ссылки на изоляцию таблицы страниц ядра.
blubberdiblub
4
При дальнейшем расследовании все три из этих предложений не выполняются. Grepping для isolationбудет соответствовать как Kernel/User page tables isolation: enabledи Kernel/User page tables isolation: disabled on command line.
Марк
18

Запустите следующую команду:

dmesg | grep 'page tables isolation'

Если он отображается включенным, то PTI включен. Если ничего не отображается или вы видите «отключен» в терминале, то PTI отключен. Ubuntu еще не опубликовал патч, поэтому он не будет отображать никаких сообщений.

Адиль РФ
источник
... или более поздние сообщения ядра вытеснили загрузочные сообщения из буфера журнала ядра. Если ваше ядро ​​печатает уведомления о вещах низкой серьезности, таких как странные сетевые пакеты, то сообщения во время загрузки обычно не являются частью dmesgвывода. Посмотрите, /var/log/kern.log*идет ли он достаточно далеко, чтобы получить загрузочные сообщения. Ubuntu раньше записывал dmesgвыходные данные во время загрузки /var/log/dmesg, но, похоже, больше этого не делает.
Питер Кордес
14.04 я получил dmesg: invalid option -- 'w'. -Hтакже недействителен. Снятие флагов для меня работало нормально, так как в этом ответе
wjandrea
/var/log/kern.log 14
апреля
12

Вы можете проверить cat /proc/cpuinfo, если он сообщает в cpu_insecureразделе «ошибки», то PTI включен.

Если оно пустое (или просто не cpu_insecureотображается в списке ), то, скорее всего, вы используете ядро, которое еще не было исправлено (Ubuntu не имеет), или у вас есть процессор AMD (для которого это, вероятно, не будет включено, так как они не уязвимы).

В настоящее время все процессоры считаются уязвимыми в последнем ядре 4.15.

JonasCz - Восстановить Монику
источник
4.15 еще не выпущено для публики
Aadhil RF
Это так, если вы скачаете последнюю версию кандидата с kernel.org и скомпилируете ее самостоятельно. @Mohammedaadhil
JonasCz - Восстановить Монику
1
Релиз-кандидат не является релизом.
Руслан
2
Ядро 4.14.11 будет установлено cpu_insecureдля любого процессора x86; 4.14.12 и новее будут устанавливать его только для процессоров Intel (включая слишком старые или слишком примитивные, чтобы быть уязвимыми. Оба будут устанавливать его, даже если KPTI отключен.
Отметить
8

Я нашел этот отличный сценарий sh для проверки уязвимостей Meltdown / Spectre в вашей системе:

https://github.com/speed47/spectre-meltdown-checker

Сценарий проверяет вашу систему на наличие известных исправлений Meltdown и Spectre в вашей системе, чтобы сообщить вам, устранены ли эти уязвимости вашей ОС.

Compte Droid
источник
2

Вы можете проверить /proc/config.gz для CONFIG_PAGE_TABLE_ISOLATION=yэто означает , что ядро скомпилировано с КПТИ.

Это на моей исправленной системе Arch Linux под управлением 4.14.11-1:

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz 
CONFIG_PAGE_TABLE_ISOLATION=y
Raniz
источник
3
К сожалению, конфигурация текущего запущенного ядра в /proc/не включена по умолчанию в ядрах Ubuntu. Вместо /boot/config-$( uname -r )этого (гораздо менее элегантный) обходной путь
blubberdiblub
5
Это говорит только о том, было ли ядро ​​скомпилировано с KPTI, а не о том, активен ли KPTI (его можно отключить во время загрузки и, возможно, во время выполнения).
Mark
Если вы явно отключили KPTI через параметры командной строки ядра, вам не нужно проверять, активен он или нет.
Ранис
1

На моем экземпляре AWS Ubuntu 14.04.5 LTS EC2 я запустил

grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-$(uname -r)

Следует сказать:

CONFIG_PAGE_TABLE_ISOLATION=y

Для обновления я сделал:

sudo apt-get update && sudo apt-get install linux-image-generic

Я думаю, что это тоже нормально:

sudo apt-get update
sudo apt-get dist-upgrade

Чтобы проверить версию ядра:

uname -r

Должен быть 3.13.0-139-родовым или более новым.

drKreso
источник
Этот метод уже упоминался в верхнем ответе
wjandrea