Wie überprüfe ich, ob KPTI auf meinem Ubuntu aktiviert ist?


64

Die aktuelle Sicherheitsanfälligkeit in Meltdown Intel-Prozessoren wird derzeit behoben, indem die Seitentabellenisolierung aktiviert wird. Es gibt eine Frage, wie Sie dies deaktivieren können : Wie Sie die Seitentabellenisolation deaktivieren, um die aufgrund des Sicherheitslücken-Patches für die Intel-CPU verlorene Leistung wiederherzustellen?

Meine Frage ist umgekehrt: Gibt es eine Möglichkeit, auf einem laufenden System zu überprüfen, ob der PTI-Mechanismus auf dem System wirksam ist und somit das System geschützt ist? Ich bin speziell auf der Suche nach cat /proc/somethingoder cat /sys/somethingnicht auf Kernel-Version oder Konfigurationsparameter oder dergleichen zu überprüfen.

Antworten:


4

Sie können den folgenden Befehl ausführen, um alle verfügbaren Abhilfemaßnahmen anzuzeigen (nicht nur für PTI, sondern auch für andere Sicherheitsanfälligkeiten):

$ 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

Geniale Antwort - kurz und bündig. Danke.
Martin Vysny

63
  • Das Begrüßen von CONFIG_PAGE_TABLE_ISOLATION in der Kernel-Konfiguration, wie von Raniz vorgeschlagen, hilft nicht auf Ubuntu-Desktops, kann aber auf Cloud-Instanzen helfen:

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

  • Sie können mit überprüfen, /proc/cpuinfowie JonasCz vorgeschlagen hat :

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

  • Oder von dmesg(danke an Jason Creighton ):

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

  • Sie können ein Testprogramm von Raphael Carvalho für die Meltdown-Erkennung kompilieren :

    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
    

Auf gepatchten Systemen sollte es mit der Ausgabe enden

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

Auf gepatchten Systemen sollte Folgendes angezeigt werden:

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)

Installieren Sie 4.4.0-108-generic nicht auf Xenial! Es bricht die Boot- / Neustart- / Shutdown- / Suspend-Funktionalität ab !

Installieren Sie 4.4.0-109-generic ( Details siehe USN-3522-3 )!


Wie Robie Basak bereits schrieb , gibt es in Ubuntu eine Seite über den Schwachstellenstatus von Spectre und Meltdown .

Es gibt auch:


3
Updates für Ubuntu sind für Januar 9 geplant. Sie könnten früher landen, aber ich würde nicht damit rechnen. insights.ubuntu.com/2018/01/04/…
Raniz

4
Die Antworten vom Typ "dmesg | grep isolation" sind dieser IMO vorzuziehen. Einige Distributionen (zumindest Debian, vielleicht andere) portierten PTI auf ihren älteren Kernel, aber nicht das cpu_insecure-Flag in / proc / cpuinfo. Auf diesen Systemen ist die Suche im Dmesg-Protokoll die einzige Möglichkeit, AFAICT zu überprüfen.
Jason Creighton

3
Ich denke, der hier aufgeführte dmesg | grep isolation && echo "patched :)" || echo "unpatched :("Befehl ist unnötig gefährlich : Er zeigt nicht an, welche Zeile tatsächlich abgeglichen wurde, und würde auch gerne "gepatcht :)" ausgeben, wenn eine zufällige andere Instanz von "Isolation" abgeglichen wurde ...
Jaap Eldering

2
Ich würde gegen den zweiten Vorschlag empfehlen (grepping /proc/cpuinfofor cpu_insecure). Wenn Sie dies in ein Skript einfügen und in Zukunft eine CPU haben, bei der das Problem in der Mikroarchitektur behoben ist, /proc/cpuinfowird dies nicht mehr angezeigt cpu_insecureund Ihr Skript glaubt, dass der Kernel ungepatcht ist , obwohl er gepatcht ist . Ich würde auch gegen den dritten Vorschlag raten, da es zu wahrscheinlich ist, dass irgendwann das Wort isolationin der dmesgAusgabe vorkommt, ohne dass es sich auf die Kernel-Seitentabellen-Isolation bezieht.
Blubberdiblub

4
Bei weiteren Untersuchungen sind alle drei Vorschläge ungültig. Greifen nach isolationwird mit Kernel/User page tables isolation: enabledund übereinstimmen Kernel/User page tables isolation: disabled on command line.
Mark

18

Führen Sie den folgenden Befehl aus:

dmesg | grep 'page tables isolation'

Wenn aktiviert angezeigt wird, ist PTI aktiviert. Wenn im Terminal nichts angezeigt wird oder Sie "disabled" sehen, ist PTI deaktiviert. Ubuntu hat den Patch noch nicht veröffentlicht, daher wird keine Meldung angezeigt.


... oder neuere Kernelnachrichten haben die Startnachrichten aus dem Kernelprotokollpuffer verschoben. Wenn Ihr Kernel Benachrichtigungen für Dinge mit niedrigem Schweregrad wie seltsame Netzwerkpakete druckt, ist es üblich, dass die Startnachrichten nicht Teil der dmesgAusgabe sind. Prüfen Sie, /var/log/kern.log*ob es weit genug zurückreicht, um die Startmeldungen zu erhalten. Ubuntu zeichnete die dmesgAusgabe /var/log/dmesgwährend des Startvorgangs auf , scheint dies aber nicht mehr zu tun.
Peter Cordes

Am 14.04 habe ich bekommen dmesg: invalid option -- 'w'. -Hist auch ungültig. Das Entfernen der Flags hat für mich gut funktioniert, wie in dieser Antwort
wjandrea

/var/log/kern.log am 14.04
eckes

12

Sie können mit überprüfen cat /proc/cpuinfo, ob es cpu_insecureunter "Bugs" meldet , dann ist PTI aktiviert.

Wenn es leer ist (oder einfach nicht aufgelistet wird cpu_insecure), führen Sie höchstwahrscheinlich einen Kernel aus, der noch nicht gepatcht wurde (Ubuntu hat es nicht), oder Sie haben einen AMD-Prozessor (für den dies absehbar nicht aktiviert ist, da sie sind nicht verwundbar).

Gegenwärtig werden alle CPUs im neuesten 4.15-Kernel als anfällig behandelt .


4.15 ist noch nicht für die Öffentlichkeit
freigegeben

Dies ist der Fall , wenn Sie den neuesten Release Candidate von kernel.org herunterladen und selbst kompilieren. @ Mohammedaadhil
JonasCz sagt Reinstate Monica

1
Ein Release-Kandidat ist kein Release.
Ruslan

Der von Ihnen verlinkte Artikel wurde aktualisiert
nixpower

2
Kernel 4.14.11 wird cpu_insecurefür jede x86-CPU eingestellt. 4.14.12 und neuer setzt sie nur für Intel - CPUs (darunter auch solche , zu alt oder zu primitiv , verletzlich sein Sowohl es auch wenn KPTI deaktiviert eingestellt wird..
Mark

8

Ich habe dieses großartige sh-Skript gefunden, um Meltdown / Spectre-Schwachstellen auf Ihrem System zu testen:

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

Das Skript überprüft Ihr System auf bekannte Meltdown- und Spectre-Patches auf Ihrem System, um Ihnen mitzuteilen, ob diese Sicherheitsanfälligkeiten jetzt von Ihrem Betriebssystem behoben werden


2

Sie können prüfen , /proc/config.gz für CONFIG_PAGE_TABLE_ISOLATION=ywas bedeutet , dass der Kernel mit KPTI kompiliert wurde.

Dies ist auf meinem gepatchten Arch Linux-System unter 4.14.11-1:

$ zgrep CONFIG_PAGE_TABLE_ISOLATION /proc/config.gz 
CONFIG_PAGE_TABLE_ISOLATION=y

3
Leider ist die Konfiguration des aktuell ausgeführten Kernels /proc/in Ubuntu-Kerneln nicht standardmäßig aktiviert. Die (viel weniger elegante) Problemumgehung greift /boot/config-$( uname -r )stattdessen.
Blubberdiblub

5
Das sagt Ihnen nur, ob der Kernel mit KPTI kompiliert wurde, nicht, wenn KPTI aktiv ist (es kann beim Booten und möglicherweise zur Laufzeit deaktiviert werden).
Mark

Wenn Sie KPTI über Kernel-Befehlszeilenparameter explizit deaktiviert haben, sollten Sie nicht prüfen müssen, ob es aktiv ist oder nicht.
Raniz

1

Auf meiner AWS Ubuntu 14.04.5 LTS EC2-Instanz wurde ich ausgeführt

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

Es sollte heißen:

CONFIG_PAGE_TABLE_ISOLATION=y

Für das Update habe ich:

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

Ich denke auch das ist OK:

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

So überprüfen Sie die Kernelversion:

uname -r

Muss sein 3.13.0-139-generic oder neuer.


Diese Methode ist bereits in der Top-Antwort erwähnt
wjandrea
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.