Schutzmassnahmen gegen CPU-Schwachstellen

Im Modus High Security aktiviert Ditana standardmässig Schutzmassnahmen gegen CPU-Schwachstellen. Das Installationsprogramm erkennt, welche Schutzmassnahmen Ihre CPU konkret braucht, indem es /sys/devices/system/cpu/vulnerabilities/ ausliest, und bietet dann jede davon als eigenes, einzeln schaltbares Kontrollkästchen im Dialog Expert Settings → CPU Vulnerability Mitigation Options an. Diese Seite dokumentiert jede Option im Detail.

Standardeinstellungen des Kernels im Vergleich zu Ditanas Schutzmassnahmen

Die Upstream-Voreinstellungen von Linux wägen Sicherheit gegen Leistung ab und lassen bestimmte Schwachstellen ohne Schutzmassnahme, sofern diese nicht ausdrücklich eingeschaltet wird. Ditana schaltet sie standardmässig ein – für die meisten Arbeitslasten sind die Kosten vernachlässigbar, während der Sicherheitsgewinn beträchtlich ist. Sie können jede einzelne Schutzmassnahme im Installationsprogramm rückgängig machen, wenn Sie eine Arbeitslast haben, die nachweislich davon profitiert.

Die Logik der Schutzmassnahmen ist hardwarespezifisch. Eingerichtet werden nur die Schwachstellen, die Ihre CPU tatsächlich aufweist; für alles andere bleibt es bei der Voreinstellung des Kernels.

Nach der Installation

Mehrere Schutzmassnahmen sehen als Ausweichlösung vor, Simultaneous Multi-Threading (SMT, auch als Hyper-Threading bekannt) zu deaktivieren. Ditanas eigene Kopfzeile im Terminal zeigt, welche Schutzmassnahmen aktiv sind und ob SMT ein- oder ausgeschaltet ist.

Sie können dies auch mit folgendem Befehl überprüfen:

lscpu

Um die Leistung mit und ohne eine bestimmte Schutzmassnahme zu vergleichen, bearbeiten Sie die Kernel-Befehlszeile für einen einzelnen Systemstart und entfernen Sie den Parameter, der zu der Schutzmassnahme gehört, die Sie testen möchten. Bei einer ZFS-Installation, wie sie das Profil Standard erzeugt, geschieht das über den Editor für Boot-Umgebungen von ZFSBootMenu; auf einem System, das über GRUB startet, drücken Sie im Menü e. Die Parameter stehen unten bei jedem Eintrag unter «Gesetzter Parameter». Starten Sie neu und führen Sie Ihre tatsächliche Arbeitslast aus – synthetische Benchmarks bilden die tatsächlichen Auswirkungen selten ab.

Um eine Änderung bei einer ZFS-Installation dauerhaft zu machen, setzen Sie die Befehlszeile in der Boot-Umgebung:

sudo zfs set org.zfsbootmenu:commandline="rw <options>" ditana-root/ROOT
zfs get org.zfsbootmenu:commandline ditana-root/ROOT

Um sie auf einem System, das über GRUB startet, dauerhaft zu machen, bearbeiten Sie /etc/default/grub, suchen Sie die Zeile GRUB_CMDLINE_LINUX_DEFAULT (legen Sie zuerst eine Sicherungskopie an), entfernen Sie den Parameter und führen Sie dann Folgendes aus:

sudo grub-mkconfig -o /boot/grub/grub.cfg

Wenn eine Änderung den Systemstart verhindert, bearbeiten Sie die Kernel-Befehlszeile im GRUB-Menü, um wieder starten zu können, und wiederholen Sie dann die Bearbeitung und grub-mkconfig.

Schutzmassnahmen, die Ditana standardmässig aktiviert

Spectre-Variante 2 – Branch Target Injection

Exploit, der die spekulative Ausführung ausnutzt und über falsch trainierte Sprungvorhersagen für indirekte Verzweigungen das Auslesen sensibler Daten ermöglicht. Ditana wendet die vollständige Schutzmassnahme an (Indirect Branch Prediction Barrier immer aktiv statt nur unter Bedingungen).

Alle Schutzmassnahmen gegen Spectre-Variante 2 können beim Systemstart für alle Programme erzwungen werden. Das verursacht Mehraufwand, da die Spekulation bei indirekten Verzweigungen für alle Programme eingeschränkt wird.

– kernel.org: Spectre

Bezeichner in lscpu	Spectre v2
Name der Einstellung	Enforce Spectre Variant 2 Mitigation
Gesetzter Parameter	spectre_v2=on

L1 Terminal Fault (L1TF)

Betrifft Intel-CPUs und ermöglicht unbefugten Zugriff auf Daten im L1-Cache. Ditana erzwingt die vollständige Schutzmassnahme mit aggressivem Leeren des Caches.

Der Kernel erzwingt standardmässig nicht die Deaktivierung von SMT, wodurch SMT-Systeme anfällig bleiben, wenn nicht vertrauenswürdige Gäste mit aktiviertem EPT laufen.

– kernel.org: L1TF

Bezeichner in lscpu	L1tf
Name der Einstellung	Enforce L1 Terminal Fault Mitigation
Gesetzter Parameter	l1tf=full,force

Microarchitectural Data Sampling (MDS)

Ermöglicht Angriffe, bei denen Daten aus Puffern der CPU abgegriffen werden. Die vollständige Schutzmassnahme kann SMT bei Bedarf deaktivieren.

Der Kernel erzwingt standardmässig nicht die Deaktivierung von SMT, wodurch SMT-Systeme anfällig bleiben, wenn nicht vertrauenswürdiger Code ausgeführt wird.

– kernel.org: MDS

Bezeichner in lscpu	Mds
Name der Einstellung	Enforce MDS Mitigation
Gesetzter Parameter	mds=full,nosmt

TSX Asynchronous Abort (TAA)

Betrifft CPUs mit Transactional Synchronization Extensions. Die vollständige Schutzmassnahme kann SMT deaktivieren, falls erforderlich.

TSX wird möglicherweise deaktiviert, wenn der Microcode ein MSR zur Steuerung von TSX bereitstellt. In diesem Fall ist das System nicht anfällig.

– kernel.org: TAA

Bezeichner in lscpu	Tsx async abort
Name der Einstellung	Enforce TSX Async Abort Mitigation
Gesetzter Parameter	tsx_async_abort=full,nosmt

Meltdown (Leeren des L1D-Caches)

Exploit, der die spekulative Ausführung ausnutzt und das Auslesen von Kernel-Speicher aus dem Userspace ermöglicht. Ditana erzwingt das Leeren des L1-Datencaches.

Über die Kernel-Befehlszeile lassen sich die Schutzmassnahmen durch Leeren des L1D beim Systemstart mit der Option l1d_flush= steuern. Standardmässig ist der Mechanismus deaktiviert.

– kernel.org: L1D flush

Bezeichner in lscpu	Meltdown
Name der Einstellung	Enforce Meltdown Mitigation
Gesetzter Parameter	l1d_flush=on

MMIO Stale Data

Datenabfluss aus speicherabgebildeter Ein- und Ausgabe. Die vollständige Schutzmassnahme kann SMT deaktivieren.

full,nosmt – Wie full, aber mit deaktiviertem SMT auf anfälligen CPUs. Das ist die vollständige Schutzmassnahme.

– kernel.org: MMIO stale data

Bezeichner in lscpu	Mmio stale data
Name der Einstellung	Enforce MMIO Stale Data Mitigation
Gesetzter Parameter	mmio_stale_data=full,nosmt

Retbleed – Cross-Thread Return Address Predictions

Angriff, der die spekulative Ausführung ausnutzt und Rücksprungadressen preisgibt. Die automatisch gewählte Schutzmassnahme kann SMT deaktivieren.

auto,nosmt – automatisch eine Schutzmassnahme wählen und dabei SMT deaktivieren, falls das für die vollständige Schutzmassnahme nötig ist.

– kernel.org: kernel parameters

Bezeichner in lscpu	Retbleed
Name der Einstellung	Enforce Retbleed Mitigation
Gesetzter Parameter	retbleed=auto,nosmt

Siehe auch kernel.org: Cross-Thread Return Address Predictions.

Speculative Return Stack Overflow (SRSO)

Spekulative Angriffe über den Return Stack Buffer. Kombiniert IBPB-Barrieren mit dem strikten Modus von spectre_v2-user.

Mitigation: IBPB: Ähnlicher Schutz wie «safe RET», setzt aber beim Wechsel zwischen Berechtigungsdomänen (Benutzermodus→Kernel, Gast→Host) eine IBPB-Barriere ein.

– kernel.org: SRSO

Bezeichner in lscpu	Spec rstack overflow
Name der Einstellung	Enforce SRSO Mitigation
Gesetzter Parameter	spec_rstack_overflow=ibpb spectre_v2_user=on

Gather Data Sampling (GDS)

Betrifft AVX-Befehle. Erzwingt die Schutzmassnahme per Microcode oder deaktiviert AVX, wo kein Microcode verfügbar ist.

Mit gather_data_sampling=force wird die Schutzmassnahme per Microcode verwendet, sofern verfügbar, oder AVX auf betroffenen Systemen deaktiviert, deren Microcode nicht so aktualisiert wurde, dass er die Schutzmassnahme enthält.

– kernel.org: Gather Data Sampling

Bezeichner in lscpu	Gather data sampling
Name der Einstellung	Enforce Gather Data Sampling Mitigation
Gesetzter Parameter	gather_data_sampling=force

Register File Data Sampling (RFDS)

Ermöglicht das Abgreifen von Daten aus Registern der CPU.

Dieser Parameter überschreibt den Standardwert, der beim Kompilieren durch CONFIG_MITIGATION_RFDS festgelegt wurde.

– kernel.org: kernel parameters

Bezeichner in lscpu	Reg file data sampling
Name der Einstellung	Enforce RFDS Mitigation
Gesetzter Parameter	reg_file_data_sampling=on

Siehe auch kernel.org: RFDS.

Schwachstellen, die das Installationsprogramm nicht anbietet

Für diese wendet der Kernel standardmässig die grösstmöglichen Schutzmassnahmen an – Ditana hat nichts hinzuzufügen.

Fünf weitere werden vom Kernel gemeldet und oben nirgends genannt, weil Ditana auch zu ihnen nichts hinzufügt: Ghostwrite, Indirect Target Selection, veralteter Microcode, TSA und VMSCAPE. Der Kernel entscheidet anhand des Prozessors, den er vorfindet, was jede von ihnen braucht, und hinterlegt das Ergebnis dort, wo lscpu und /sys/devices/system/cpu/vulnerabilities/ es anzeigen.

Spectre-Variante 1 – Bounds Check Bypass

Es gibt keine Garantie, dass alle möglichen Angriffsvektoren für Spectre-Variante 1 abgedeckt sind.

– kernel.org: Spectre

Bezeichner in lscpu: Spectre v1

iTLB multihit

Bezeichner in lscpu: Itlb multihit. Siehe kernel.org: iTLB multihit.

SRBDS – Special Register Buffer Data Sampling

Bezeichner in lscpu: Srbds. Siehe kernel.org: SRBDS.

Speculative Store Bypass (SSB)

Der Kernel bietet Schutzmassnahmen gegen solche Schwachstellen in verschiedenen Formen.

– kernel.org: spec_ctrl

Bezeichner in lscpu: Spec store bypass.

Abschwächung der Schutzmassnahmen – auf eigenes Risiko

Das Installationsprogramm bietet ausserdem zwei Optionen an, die Schutzmassnahmen abschwächen. Sie erhöhen Ihre Gefährdung durch bekannte CPU-Schwachstellen erheblich. Verwenden Sie sie nur aus einem klaren, stichhaltigen Grund.

Intel Indirect Branch Tracking deaktivieren – ibt=off

Schaltet das Indirect Branch Tracking des Kernels aus. IBT ist die Hälfte der Control-flow Enforcement Technology, die den Kontrollfluss in Vorwärtsrichtung (forward edge) absichert – die Hardware prüft, dass jeder indirekte Sprung oder Aufruf auf einem Befehl endbr landet, und genau das erschwert Jump-Oriented Programming und Call-Oriented Programming. Es handelt sich um Kontrollflussintegrität, nicht um eine Schutzmassnahme gegen spekulative Ausführung: Branch Target Injection ist Spectre v2, weiter oben unter spectre_v2=on ausführlich behandelt. Dieser Kernelparameter ist in der offiziellen Referenz der Kernelparameter nicht dokumentiert, obwohl er bei bestimmten Distributionen häufig standardmässig aktiviert ist, ohne dass dies ausdrücklich mitgeteilt wird.

Die andere Hälfte von CET, den Shadow Stack im Userspace, dokumentiert der Kernel unter shstk; IBT selbst hat dort keine eigene Seite.

Alle Schutzmassnahmen deaktivieren – mitigations=off

Das wirkt stärker, als im Dialog jede einzelne Schutzmassnahme abzuwählen. Mit mitigations=off überspringt der Kernel jede Schutzmassnahme, die er kennt – auch die, die Ditana nicht anbietet, weil sie standardmässig aktiv sind. Die Obergrenze der Leistung steigt; die Untergrenze der Sicherheit sinkt, und zwar drastisch.

Nur sinnvoll für Benchmarks, vom Netz isolierte Systeme unter voller physischer Kontrolle oder Umgebungen, in denen Sie grundlegend andere Schutzvorkehrungen haben.

Siehe kernel.org: kernel parameters.

Haftungsausschluss

Die Hinweise auf dieser Seite beruhen auf der offiziellen Dokumentation zu CPU-Schwachstellen und der Referenz der Parameter für die Kernel-Befehlszeile. Verschiedene Kernel-Zweige weichen gelegentlich auf subtile Weise von diesen Voreinstellungen ab; unsere Tests decken die von Ditana unterstützten Kernel ab, aber ungewöhnliche Hardware-Kombinationen können zu Sonderfällen führen.

Wenn Sie eine Arbeitslast haben, die von einem anderen Standardwert profitiert, oder wenn Sie ein CPU-Modell finden, bei dem Ditanas Erkennung unvollständig oder fehlerhaft ist: Bitte eröffnen Sie ein Issue auf GitHub oder schreiben Sie ein E-Mail an [email protected]. Die Erkennungslogik besteht aus Daten, nicht aus Code – Verbesserungen sind deshalb meist nur ein paar KDL-Zeilen.