Вопросы Теги

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

Для рабочего стола

Нет разницы.

Для сервера?

Управление пространством и резервное копирование.

Если в вашей системе есть много пользователей, вы можете сделать дополнительный раздел для / home /, тогда пользователи не будут извлекать это пространство, а root (/) не будут затронуты.

Вы также можете монтируйте NFS, SMB или разделы на других физических дисках в этих папках. Например:

/ dev / sda1 / boot (1GB)

/ dev / sda2 / (60GB)

nfs: // IP / folder / home (X TB)

/ dev / sdb1 / var (1TB для / var / www или / var / ftp)

Для ноутбука

/ on m- sata (быстрый)

/ var / home / opt / tmp на hdd (медленный)

61
задан 4 January 2018 в 23:10

18 ответов

Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, поскольку предложенный Raniz не помогает на рабочем столе Ubuntu, но может помочь в облачных экземплярах: 
grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \
echo "patched :)" || echo "unpatched :("
Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра как предложил Ранис, не помогает на рабочем столе Ubuntu, но может помочь в облачных экземплярах: 
grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \
echo "patched :)" || echo "unpatched :("

Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, как предложил Ранис не помогает на рабочем столе Ubuntu, но может помочь в облачных экземплярах: 

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

Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, поскольку предложенный Ранисом помощь на рабочем столе Ubuntu, но может помочь в облачных экземплярах: 

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

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

...
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

на исправленной системе он должен завершиться выходом [!d19 ] 

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 ().

разрывает загрузку / перезагрузку / выключение / приостановку функциональности ! ]

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

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

Проверьте с помощью инструмента 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
Бюллетень Ubuntu Security для CVE-2017-5753 Бюллетень Ubuntu Security для CVE-2017-5754
62
ответ дан 22 May 2018 в 15:46
  • 1
    Обновления для Ubuntu запланированы на Januari 9. Они могут приземляться раньше, но я не буду рассчитывать на это. insights.ubuntu.com/2018/01/04/&hellip – Raniz 5 January 2018 в 10:48
  • 2
    «Dmesg | Grep-изоляция " тип ответов предпочтительнее, ИМО. Некоторые дистрибутивы (по крайней мере, Debian stretch, возможно, другие) портировали PTI на их старшее ядро, но не флаг cpu_insecure в / proc / cpuinfo. В этих системах просмотр в журнале dmesg - единственный способ проверить, AFAICT. – Jason Creighton 6 January 2018 в 22:03
  • 3
    Я думаю, что команда dmesg | grep isolation && echo "patched :)" || echo "unpatched :(", указанная в списке, необязательно опасна : она не показывает, какая строка была фактически сопоставлена, а также успешно печаталась и исправлена:) " если случайный другой экземпляр "изоляции" был сопоставлен ... – Jaap Eldering 7 January 2018 в 00:24
  • 4
    Я бы рекомендовал против второго предложения (grepping /proc/cpuinfo для cpu_insecure). Если вы поместите это в скрипт и у вас будет процессор в будущем, где проблема будет исправлена ​​в его микроархитектуре, /proc/cpuinfo больше не скажет cpu_insecure, и ваш сценарий будет считать, что ядро ​​ не отправлено даже если он исправлен . Я бы также рекомендовал против третьего предложения, так как слишком вероятно, что в какой-то момент может появиться слово isolation на выходе dmesg без ссылки на изоляцию таблицы страниц ядра. – blubberdiblub 7 January 2018 в 08:28
  • 5
    После дальнейшего расследования все три этих предложения нарушены. Grepping для isolation будет соответствовать как Kernel/User page tables isolation: enabled, так и Kernel/User page tables isolation: disabled on command line. – Mark 7 January 2018 в 11:31
Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, поскольку предложенный Raniz не помогает на рабочем столе Ubuntu, но может помочь в облачных экземплярах: grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \ echo "patched :)" || echo "unpatched :(" Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра как предложил Ранис, не помогает на рабочем столе Ubuntu, но может помочь в облачных экземплярах: grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \ echo "patched :)" || echo "unpatched :("

Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, как предложил Ранис не помогает на рабочем столе Ubuntu, но может помочь в облачных экземплярах:

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

Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, поскольку предложенный Ранисом помощь на рабочем столе Ubuntu, но может помочь в облачных экземплярах:

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

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

... 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 ().

разрывает загрузку / перезагрузку / выключение / приостановку функциональности ! ]

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

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

Проверьте с помощью инструмента 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 Бюллетень Ubuntu Security для CVE-2017-5753 Бюллетень Ubuntu Security для CVE-2017-5754
62
ответ дан 17 July 2018 в 23:54
Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, поскольку предложенный Raniz не помогает на рабочем столе Ubuntu, но может помочь в облачных экземплярах: grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \ echo "patched :)" || echo "unpatched :(" Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра как предложил Ранис, не помогает на рабочем столе Ubuntu, но может помочь в облачных экземплярах: grep CONFIG_PAGE_TABLE_ISOLATION=y /boot/config-`uname -r` && \ echo "patched :)" || echo "unpatched :("

Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, как предложил Ранис не помогает на рабочем столе Ubuntu, но может помочь в облачных экземплярах:

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

Grepping CONFIG_PAGE_TABLE_ISOLATION в конфигурации ядра, поскольку предложенный Ранисом помощь на рабочем столе Ubuntu, но может помочь в облачных экземплярах:

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

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

... 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 ().

разрывает загрузку / перезагрузку / выключение / приостановку функциональности ! ]

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

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

Проверьте с помощью инструмента 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 Бюллетень Ubuntu Security для CVE-2017-5753 Бюллетень Ubuntu Security для CVE-2017-5754
62
ответ дан 24 July 2018 в 17:07

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

dmesg | grep 'page tables isolation'

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

18
ответ дан 22 May 2018 в 15:46
  • 1
    ... или более поздние сообщения ядра вытолкнули загрузочные сообщения из буфера журнала ядра. Если ваше ядро ​​печатает уведомления о материалах с низкой степенью серьезности, таких как странные сетевые пакеты, обычно для сообщений о времени загрузки не является частью вывода dmesg. См. [F2], если он возвращается достаточно далеко, чтобы иметь загрузочные сообщения. Ubuntu использовал для записи времени загрузки dmesg в /var/log/dmesg, но, похоже, больше этого не делает. – Peter Cordes 10 January 2018 в 18:23
  • 2
    14.04 я получил dmesg: invalid option -- 'w'. -H также недействителен. Удаление флагов работало отлично для меня, как в этот ответ – wjandrea 12 January 2018 в 00:14
  • 3
    /var/log/kern.log - 14.04 – eckes 12 January 2018 в 02:43

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

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

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

12
ответ дан 22 May 2018 в 15:46
  • 1
    4.15 еще не выпущен общественности – AadhilRF 4 January 2018 в 12:25
  • 2
    Это, если вы загрузите последнего релиза-кандидата из kernel.org и скомпилируйте его самостоятельно. @Mohammedaadhil – JonasCz 4 January 2018 в 12:28
  • 3
    Кандидат на выпуск не является выпуском. – Ruslan 4 January 2018 в 19:36
  • 4
    Связанная с вами статья обновлена ​​ – nixpower 4 January 2018 в 23:38
  • 5
    Kernel 4.14.11 установит cpu_insecure для любого процессора x86; 4.14.12 и новее будет устанавливать его только для процессоров Intel (в том числе слишком старых или слишком примитивных, чтобы быть уязвимыми). Оба установят его, даже если KPTI отключен. – Mark 7 January 2018 в 09:38

Я нашел этот большой скрипт для проверки уязвимостей Meltdown / specter в вашей системе:

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

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

8
ответ дан 22 May 2018 в 15:46

Вы можете проверить /proc/config.gz для CONFIG_PAGE_TABLE_ISOLATION=y, что означает, что ядро ​​было скомпилировано с помощью KPTI.

Это на моей исправленной системе Arch Linux, работающей на 4.14.11-1: 

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz 
CONFIG_PAGE_TABLE_ISOLATION=y
2
ответ дан 22 May 2018 в 15:46
  • 1
    К сожалению, конфигурация текущего ядра в /proc/ не включена по умолчанию в ядрах Ubuntu. Обходным путем (гораздо менее элегантным) является grepping /boot/config-$( uname -r ). – blubberdiblub 7 January 2018 в 08:35
  • 2
    Это говорит только о том, было ли скомпилировано ядро ​​с KPTI, а не если KPTI активен (его можно отключить во время загрузки и, возможно, во время выполнения). – Mark 7 January 2018 в 09:31
  • 3
    Если вы явно отключили KPTI через параметры командной строки ядра, вам не нужно проверять, активен он или нет. – Raniz 16 January 2018 в 11:53

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

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

Он должен сказать: 

CONFIG_PAGE_TABLE_ISOLATION=y

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

[ f3]

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

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

Проверить версию ядра: 

uname -r

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

1
ответ дан 22 May 2018 в 15:46

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

dmesg | grep 'page tables isolation'

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

18
ответ дан 17 July 2018 в 23:54

Я нашел этот большой скрипт для проверки уязвимостей Meltdown / specter в вашей системе:

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

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

8
ответ дан 17 July 2018 в 23:54

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

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

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

12
ответ дан 17 July 2018 в 23:54

Вы можете проверить /proc/config.gz для CONFIG_PAGE_TABLE_ISOLATION=y, что означает, что ядро ​​было скомпилировано с помощью KPTI.

Это на моей исправленной системе Arch Linux, работающей на 4.14.11-1:

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz CONFIG_PAGE_TABLE_ISOLATION=y
2
ответ дан 17 July 2018 в 23:54

В моем экземпляре 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-родовым или новым.

1
ответ дан 17 July 2018 в 23:54

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

dmesg | grep 'page tables isolation'

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

18
ответ дан 24 July 2018 в 17:07
  • 1
    ... или более поздние сообщения ядра вытолкнули загрузочные сообщения из буфера журнала ядра. Если ваше ядро ​​печатает уведомления о материалах с низкой степенью серьезности, таких как странные сетевые пакеты, обычно для сообщений о времени загрузки не является частью вывода dmesg. См. [F2], если он возвращается достаточно далеко, чтобы иметь загрузочные сообщения. Ubuntu использовал для записи времени загрузки dmesg в /var/log/dmesg, но, похоже, больше этого не делает. – Peter Cordes 10 January 2018 в 18:23
  • 2
    14.04 я получил dmesg: invalid option -- 'w'. -H также недействителен. Удаление флагов работало отлично для меня, как в этот ответ – wjandrea 12 January 2018 в 00:14
  • 3
    /var/log/kern.log - 14.04 – eckes 12 January 2018 в 02:43

Я нашел этот большой скрипт для проверки уязвимостей Meltdown / specter в вашей системе:

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

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

8
ответ дан 24 July 2018 в 17:07

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

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

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

12
ответ дан 24 July 2018 в 17:07
  • 1
    4.15 еще не выпущен общественности – AadhilRF 4 January 2018 в 12:25
  • 2
    Это, если вы загрузите последнего релиза-кандидата из kernel.org и скомпилируйте его самостоятельно. @Mohammedaadhil – JonasCz 4 January 2018 в 12:28
  • 3
    Кандидат на выпуск не является выпуском. – Ruslan 4 January 2018 в 19:36
  • 4
    Связанная с вами статья обновлена ​​ – nixpower 4 January 2018 в 23:38
  • 5
    Kernel 4.14.11 установит cpu_insecure для любого процессора x86; 4.14.12 и новее будет устанавливать его только для процессоров Intel (в том числе слишком старых или слишком примитивных, чтобы быть уязвимыми). Оба установят его, даже если KPTI отключен. – Mark 7 January 2018 в 09:38

Вы можете проверить /proc/config.gz для CONFIG_PAGE_TABLE_ISOLATION=y, что означает, что ядро ​​было скомпилировано с помощью KPTI.

Это на моей исправленной системе Arch Linux, работающей на 4.14.11-1:

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz CONFIG_PAGE_TABLE_ISOLATION=y
2
ответ дан 24 July 2018 в 17:07
  • 1
    К сожалению, конфигурация текущего ядра в /proc/ не включена по умолчанию в ядрах Ubuntu. Обходным путем (гораздо менее элегантным) является grepping /boot/config-$( uname -r ). – blubberdiblub 7 January 2018 в 08:35
  • 2
    Это говорит только о том, было ли скомпилировано ядро ​​с KPTI, а не если KPTI активен (его можно отключить во время загрузки и, возможно, во время выполнения). – Mark 7 January 2018 в 09:31
  • 3
    Если вы явно отключили KPTI через параметры командной строки ядра, вам не нужно проверять, активен он или нет. – Raniz 16 January 2018 в 11:53

В моем экземпляре 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-родовым или новым.

1
ответ дан 24 July 2018 в 17:07

Другие вопросы по тегам:

Похожие вопросы: