Wie überprüfe ich, ob im Linux-Kernel "Retpoline" aktiviert ist oder nicht?

In Bezug auf die Sicherheitslücke "Spectre" wurde "Retpoline" eingeführt, um das Risiko zu minimieren. Ich habe jedoch einen Beitrag gelesen, in dem es um Folgendes geht:

Wenn Sie den Kernel ohne erstellen CONFIG_RETPOLINE, können Sie keine Module mit retpoline erstellen und dann damit rechnen, dass sie geladen werden - da die Thunk-Symbole nicht exportiert werden.

Wenn Sie den Kernel mit dem retpoline obwohl bauen, Sie können erfolgreich Module laden , die mit retpoline nicht gebaut werden. ( Quelle )

Gibt es eine einfache und allgemeine / generische / einheitliche Möglichkeit, um zu überprüfen, ob der Kernel "Retpoline" aktiviert ist oder nicht? Ich möchte dies tun, damit mein Installer den richtigen Build des zu installierenden Kernel-Moduls verwenden kann.

linux kernel linux-kernel

— Weishan Yang
quelle

Antworten:

Wenn Sie Mainline-Kernel oder die Kernel der meisten Hauptdistributionen verwenden, können Sie am besten überprüfen, ob eine vollständige Retpoline-Unterstützung vorliegt ( dh der Kernel wurde CONFIG_RETPOLINEmit einem Retpoline-fähigen Compiler konfiguriert und wurde mit diesem erstellt) ”In /sys/devices/system/cpu/vulnerabilities/spectre_v2. Auf meinem System:

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB, IBRS_FW

Wenn Sie umfassendere Tests wünschen, um Retpolines auf Kerneln ohne die spectre_v2systree-Datei zu erkennen, lesen Sie, wie spectre-meltdown-checkerdie Dinge ablaufen .

— Stephen Kitt
quelle

Führen Sie $ grep . /sys/devices/system/cpu/vulnerabilities/*den folgenden Befehl aus, um nach weiteren Sicherheitslücken im Zusammenhang mit Meltdown / Spectre zu suchen , die in Greg Kroah-Hartmans Blog vorgeschlagen werden .

— Alex Vong

Danke @Alex; Ich habe die spezifische Frage beantwortet, aber das ist nützlich - obwohl ich head /sys/devices/system/cpu/vulnerabilities/*mich selbst bevorzuge ;-). Das deckt derzeit Meltdown / Spectre-Schwachstellen ab, sollte aber auch zukünftige Schwachstellen ähnlicher Art abdecken (der Namespace ist absichtlich allgemein gehalten).

— Stephen Kitt

@StephenKitt Ja, headgibt eine schönere formatierte Ausgabe.

— Alex Vong

Stephen Kitts Antwort ist in diesem speziellen Fall umfassender, da die Retpoline-Unterstützung auch eine neue Compiler-Version benötigt.

Im Allgemeinen verfügen die meisten Distributionen jedoch über die Kernelkonfigurationsdatei an einem der folgenden Speicherorte:

/boot/config-4.xx.xx-...
/proc/config.gz

Dann kannst du einfach zgrep CONFIG_RETPOLINE /boot/config* /proc/config.gz

— jpa
quelle

Ich empfehle, nicht einzuspringen /boot/config*, da dies CONFIG_RETPOLINEin einem Kernel-Image auftreten kann, das installiert ist, aber derzeit nicht ausgeführt wird, was ein falsches Sicherheitsgefühl vermittelt. Prüfen /proc/config.gzoder /sys/...ist sicher, aber viele Linux-Distributionen kompilieren den Kernel ohne /proc/config.gz.

— Pkt

Könntest du die Logik ein bisschen schlauer machen und uname (oder das äquivalente syscall) verwenden, um den aktuell ausgeführten Kernel zu erhalten und dann diese bestimmte / boot / config-Datei zu untersuchen?

— Adam Luchjenbroers

@pts /boot/config-$(uname -r)dann?

— muru

Die Verwendung /boot/config-$(uname -r)ist auch nicht kinderleicht: Sie garantiert immer noch nicht, dass die Konfiguration mit dem ausgeführten Kernel übereinstimmt. Distributionskerne bleiben uname -rüber mehrere Versionen hinweg gleich, solange sich die Kernel-ABI nicht ändert.

— Stephen Kitt

Vielen Dank für Ihre Antwort. Ihre Antwort und Nachricht ist hilfreich.

— Weishan Yang