Jak sprawdzić, czy KPTI jest włączony na moim Ubuntu?

64

Obecna luka w zabezpieczeniach procesora Meltdown Intel jest obecnie usuwana poprzez włączenie izolacji tablicy stron. Istnieje pytanie, jak to wyłączyć: Jak wyłączyć Izolowanie tabeli stron, aby odzyskać wydajność utraconą z powodu dziury w zabezpieczeniach procesora Intel?

Moje pytanie jest odwrotne: czy istnieje sposób sprawdzenia działającego systemu, czy mechanizm PTI działa w systemie, a zatem system jest chroniony? W szczególności szukam cat /proc/somethinglub cat /sys/somethingnie sprawdzam wersji jądra, parametru konfiguracyjnego itp.

Martin Vysny
źródło

Odpowiedzi:

4

Możesz uruchomić poniższe polecenie, aby zobaczyć wszystkie dostępne zabezpieczenia (nie tylko w przypadku PTI, ale także innych luk):

$ 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
Michał Przybylowicz
źródło
Niesamowita odpowiedź - krótko i na temat. Dziękuję Ci.
Martin Vysny
63
  • Grepping CONFIG_PAGE_TABLE_ISOLATION w konfiguracji jądra, jak sugeruje Raniz, nie pomaga w Ubuntu na komputerze, ale może pomóc w wystąpieniach chmury:

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

  • Możesz to sprawdzić, /proc/cpuinfojak sugerował JonasCz :

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

  • Lub z dmesg(dzięki Jason Creighton ):

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

  • Możesz skompilować program testowy z Raphaela Carvalho do wykrywania 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
    

w systemie załatanym powinien kończyć się wyjściem

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

W systemie załatanym powinien on pokazywać:

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)

Nie instaluj 4.4.0-108-generic na Xenial! To łamie boot / restart / wyłączenie / zawiesza funkcjonalność !

Zainstaluj 4.4.0-109-generic ( szczegóły w USN-3522-3 )!


Jak już napisał Robie Basak , w Ubuntu znajduje się strona o statusie luk w Spectre i Meltdown .

Są też:

N0rbert
źródło
3
Aktualizacje Ubuntu są zaplanowane na Januari 9. Mogą wylądować wcześniej, ale nie liczyłbym na to. insights.ubuntu.com/2018/01/04/…
Raniz
4
Odpowiedzi typu „izolacja dmesg | grep” są lepsze niż IMO. Niektóre dystrybucje (przynajmniej Debian stretch, może inne) przeniosły PTI do ich starszego jądra, ale nie flagę cpu_insecure w / proc / cpuinfo. W tych systemach przeglądanie dziennika dmesg jest jedynym sposobem sprawdzenia, AFAICT.
Jason Creighton
3
Wydaje mi się, że dmesg | grep isolation && echo "patched :)" || echo "unpatched :("polecenie wymienione poniżej jest niepotrzebnie niebezpieczne : nie pokazuje, która linia faktycznie została dopasowana, i chętnie wydrukowałoby „załatane :)”, gdyby dopasowano przypadkowe inne wystąpienie „izolacji” ...
Jaap Eldering
2
/proc/cpuinfoPoleciłbym przeciw drugiej sugestii (grepping dla cpu_insecure). Jeśli umieścisz to w skrypcie i masz procesor w przyszłości, w którym problem został rozwiązany w jego mikroarchitekturze, /proc/cpuinfonie będzie już mówić, cpu_insecurea twój skrypt uwierzy, że jądro nie jest ładowane, nawet jeśli jest załatane . Odradzałbym także trzecią sugestię, ponieważ jest zbyt prawdopodobne, że w pewnym momencie isolationw danych dmesgwyjściowych może znajdować się słowo, które nie odnosi się do izolacji tabeli stron jądra.
blubberdiblub
4
Po dalszym dochodzeniu wszystkie trzy z tych sugestii są zepsute. Grepping dla isolationdopasuje oba Kernel/User page tables isolation: enabledi Kernel/User page tables isolation: disabled on command line.
Mark
18

Uruchom następujące polecenie:

dmesg | grep 'page tables isolation'

Jeśli wyświetla się włączone, PTI jest włączone. Jeśli nic nie jest wyświetlane lub na terminalu jest wyświetlany komunikat „wyłączone”, oznacza to, że PTI jest wyłączony. Ubuntu nie opublikował jeszcze łatki, więc nie wyświetli żadnej wiadomości.

Aadhil RF
źródło
... lub później komunikaty jądra wypchnęły komunikaty rozruchowe z buforu dziennika jądra. Jeśli twoje jądro drukuje powiadomienia o rzeczach o niskim poziomie istotności, takich jak dziwne pakiety sieciowe, często komunikaty o czasie uruchamiania nie są częścią danych dmesgwyjściowych. Sprawdź, /var/log/kern.log*czy cofnie się wystarczająco daleko, aby wyświetlać komunikaty rozruchowe. Ubuntu zapisywał dmesgdane wyjściowe podczas uruchamiania /var/log/dmesg, ale wydaje się, że już tego nie robi.
Peter Cordes,
W dniu 14.04 dostałem dmesg: invalid option -- 'w'. -Hjest również nieprawidłowy. Usunięcie flag działało dla mnie dobrze, jak w tej odpowiedzi
wjandrea
/var/log/kern.log 14.04
eckes
12

Możesz sprawdzić za pomocą cat /proc/cpuinfo, jeśli zgłasza się cpu_insecurejako „błędy”, wtedy PTI jest włączony.

Jeśli jest pusty (lub po prostu nie wyświetla listy cpu_insecure), najprawdopodobniej używasz jądra, które nie zostało jeszcze załatane (Ubuntu nie ma), lub masz procesor AMD (dla którego nie można go włączyć, ponieważ nie są wrażliwe).

Obecnie wszystkie procesory są traktowane jako wrażliwe w najnowszym jądrze 4.15.

JonasCz
źródło
4.15 nie zostało jeszcze opublikowane
Aadhil RF
Jeśli pobierzesz najnowszego kandydata do wydania z kernel.org i sam go skompilujesz. @Mohammedaadhil
JonasCz
1
Kandydat do wydania nie jest wydaniem.
Ruslan
Artykuł, który
podłączyłeś,
2
Jądro 4.14.11 zostanie ustawione cpu_insecuredla dowolnego procesora x86; 4.14.12 i nowsze ustawią go tylko dla procesorów Intel (w tym tych, które są zbyt stare lub zbyt prymitywne, aby były podatne na atak. Oba ustawią go, nawet jeśli KPTI jest wyłączone.
Mark
8

Znalazłem ten świetny skrypt sh do testowania luk w systemie Meltdown / Spectre:

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

Skrypt sprawdza Twój system pod kątem znanych łat Meltdown i Spectre w twoim systemie, aby poinformować Cię, czy luki te są teraz ograniczane przez Twój system operacyjny

Compte droid
źródło
2

Można sprawdzić /proc/config.gz za CONFIG_PAGE_TABLE_ISOLATION=yco oznacza, że jądro zostało skompilowane z KPTI.

To jest na moim poprawionym systemie Arch Linux z systemem 4.14.11-1:

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz 
CONFIG_PAGE_TABLE_ISOLATION=y
Raniz
źródło
3
Niestety konfiguracja aktualnie uruchomionego jądra /proc/nie jest domyślnie włączona w jądrach Ubuntu. /boot/config-$( uname -r )Zamiast tego (znacznie mniej eleganckie) obejście to grep .
blubberdiblub
5
To mówi tylko, czy jądro zostało skompilowane z KPTI, a nie, jeśli KPTI jest aktywny (można go wyłączyć w czasie rozruchu i ewentualnie w czasie wykonywania).
Mark
Jeśli jawnie wyłączyłeś KPTI za pomocą parametrów wiersza poleceń jądra, nie musisz sprawdzać, czy jest aktywny, czy nie.
Raniz
1

Na mojej instancji AWS Ubuntu 14.04.5 LTS EC2 uruchomiłem

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

Powinien powiedzieć:

CONFIG_PAGE_TABLE_ISOLATION=y

Do aktualizacji zrobiłem:

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

Myślę też, że to jest OK:

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

Aby sprawdzić wersję jądra:

uname -r

Musi być wersja ogólna 3.13.0-139 lub nowsza.

drKreso
źródło
Ta metoda jest już wspomniana w najwyższej odpowiedzi
wjandrea,