myGully.com Boerse.SH - BOERSE.AM - BOERSE.IO - BOERSE.IM Boerse.BZ .TO Nachfolger
Ungelesen 19.01.18, 01:51   #1
Wornat1959
Profi
 
Registriert seit: Aug 2016
Beiträge: 1.859
Bedankt: 6.235
Wornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt PunkteWornat1959 leckt gerne myGully Deckel in der Kanalisation! | 2119272 Respekt Punkte
Standard Linux Kernel 4.15 bzgl. Meltdown und Spectre

Zitat:
Die Neuerungen von Linux 4.15

Thorsten Leemhuis zuletzt geändert 17.01.2018
Kernel-Log, Linux, Linux 4.15, Linux-Kernel

Das noch diesen Monat erwartete Linux 4.15 schützt vor den Auswirkungen der Sicherheitslücken Meltdown und Spectre. Ohne Performance-Verlust geht das aber auch bei Linux nicht. An weiteren Gegenmaßnahmen schrauben die Kernel-Entwickler bereits.

Die Kernel-Entwickler haben eine Reihe von Maßnahmen in Linux 4.15 integriert, die gegen die Anfang Januar veröffentlichten Sicherheitslücken Meltdown und Spectre schützen sollen:

- Gegen Meltdown greift Page Table Isolation (PTI). Einige ältere Linux-Versionen erhielten eine ältere Variante der Schutztechnik; damit ausgestattete Kernel können den mit PTI einhergehenden Performance-Verlust aber schlechter ausgleichen.
- Gegen die erste der beiden Spectre-Varianten bringt Linux bislang keinen Schutz mit; die Entwickler arbeiten aber an Kernel- und Compiler-Änderungen zur Absicherung.
- Gegen die zweite Spectre-Variante hat Linux eine "Return Trampoline" (Retpoline) genannte Technik erhalten. Volle Kraft entfaltet sie allerdings erst mit Compiler-Patches, die vielen Distributionen noch fehlen. Außerdem sollen auch noch Änderungen folgen, durch die der Kernel mehr der Spectre-v2-Schutzmaßnahmen nutzen kann, die Intel mit neuem Microcode nachrüstet.
- Über im Sysfs platzierten Dateien kann man nachsehen, gegen welche der Lücken der Prozessor anfällig ist und was der Kernel dagegen tut.

[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
(Linux 4.15 enthält noch keinen Schutz gegen die erste Spectre-Variante. Zum Schutz vor der zweiten braucht es Hilfe vom Compiler, die diesem Kernel-Image fehlt.)

Die Integration der Gegenmaßnahmen erfolgte erst spät im Entwicklungsprozess, was die Fertigstellung von Linux 4.15 um mindestens eine Woche verzögert hat. Linux 4.15 erscheint daher frühestens in der Nacht auf den 22. Januar; nach den teilweise tief ansetzenden Umbauten ist aber möglicherweise noch eine weitere Woche zur Stabilisierung der neuen Kernel-Version nötig.

Details zu den Maßnahmen gegen die zwei Sicherheitslücken lesen Sie in den folgenden Absätzen. Die weiteren Seiten dieses Artikels beschäftigen sich dann mit weiteren Änderungen, die für 4.15 vorgenommenen wurden. Diese widmen sich etwa Neuerungen rund um Infrastruktur, Sicherheitstechniken, Netzwerk-Unterstützung, Storage-Support, Dateisysteme und Grafiktreiber. In den nächsten Wochen wird der Text noch schrittweise erweitert, um darüber hinaus Neuerungen aus weiteren Bereichen zu beschreiben.

Meltdown-Schutz

Gegen Meltdown konnte man sich bereits schützen, als die Lücke am späten Abend des 3. Januar bekannt wurde. Das war der eigens entwickelten Page Table Isolation (PTI) zu verdanken, die manchmal auch Kernel PTI (KPTI) genannt wird. Mit ihrer Hilfe blendet der Kernel im Adressraum von Prozessen nicht mehr seinen ganzen Speicher ein; vielmehr findet sich dort nur noch ein kleiner Teil davon, der zur Interaktion zwischen Programmen und Kernel unerlässlich ist. Dadurch steigt der Overhead allerdings deutlich, wenn Programme für irgendwelche Aufgaben den Kernel zur Hilfe nehmen. Dieser muss dann zunächst seinen Speicher wieder einblenden, der durch das Versteckspiel auch noch aus den Caches geflogen ist.

Linus Torvalds hatte PTI am Tag vor Silvester in den Hauptentwicklungszweig integriert, aus dem kurz darauf die sechste Vorabversion von Linux 4.15 hervorging. Einige Vorarbeiten waren sogar schon in den Wochen davor eingeflossen, zahlreiche Fehlerkorrekturen folgten in den Wochen danach (1, 2, 3, 4, 5, 6, 7). Die Schutztechnik floss auch in Version 4.14.11 ein, die am 2. Januar erschien.

All das war äußerst ungewöhnlich: PTI ist eine tiefgreifende Änderung, wie sie Torvalds beim Vorbereiten neuer Versionen normalerweise nur in den ersten zwei Entwicklungswochen integriert. Solche großen Umbauten fließen eigentlich auch nie in Stable/Longterm-Kernel zurück – und schon gar nicht innerhalb von lediglich drei Tagen.

[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
(Die Dokumentation des Kernels erläutert den Ansatz von PTI.)

Durch diese Aktivitäten wurde rund um Neujahr in Linux-Kreisen schon deutlich, dass die Bekanntgabe einer größeren und schwerwiegenden Lücke kurz bevor stand. Indizien dafür hatte es schon früher gegeben, denn Kernel-Patches mit dem PTI-Vorläufer KAISER (Kernel Address Isolation to have Side-channels Efficiently Removed) hatten an der Meltdown-Entdeckung beteiligte Forscher der TU Graz bereits im Herbst veröffentlicht. Hugh Dickins hat diesen Ansatz dann mit anderen Entwickler grundlegend überarbeitet, damit er auf mehr Systemen funktioniert und den Qualitätsansprüchen der Kernel-Entwickler genügt. Später entstand unter Federführung von Thomas Gleixner dann eine neue PTI-Implementierung, die den Ansatz von KAISER verwendet, mit dessen Code aber kaum noch etwas gemein hat. Diese floss in 4.15-rc6 und 4.14.11 ein. Dort kann sie den Overhead mithilfe der in neueren Intel-Prozessoren gebotenen "Process-Context Identifiers" (PCID) reduzieren, die der Kernel seit Linux 4.14 zu nutzen weiß.

Auch die am 5. Januar erschienenen Kernel-Versionen 4.9.75 und 4.4.140 enthalten PTI – allerdings nicht die jüngste Implementation, sondern die von Dickins vorangetriebene Variante. Diese haben auch viele Distributionen integriert, die nicht ohnehin schon 4.14 verwendeten. Mit dem älteren PTI erhielten die Kernel auch PCID-Unterstützung – allerdings nur eine rudimentäre. Bei diesen Kerneln kann PCID daher nicht so viel Overhead wett machen, wie es es 4.14.11 und 4.15-rc6 können; der Performance-Einbruch kann daher größer sein.

[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
(Der Boot-Parameter "nopti" schaltet PTI ab und vermeidet so dessen Performance-Einfluss.)

Besitzer von AMD-Prozessoren brauchen dennoch keinen Geschwindigkeitsverlust fürchten: Linux deaktiviert PTI seit 4.14.12 und 4.15-rc7 automatisch, wenn es Athlon, Epyc, Ryzen & Co. vorfindet, denn die sind von Meltdown alle nicht betroffen. Bei Intel-CPUs hängt der Performance-Einbruch von der Generation ab, zu der der Prozessor gehört: Linux nutzt PCID erst bei CPUs mit Haswell-Innenleben, das beispielsweise in den seit Mitte 2013 verkauften Core-i-4000er-Prozessoren steckt; ältere Prozessoren beherrschen diese Technik nicht oder nur in einer Weise, bei der eine Nutzung keine Vorteile brächte.

PTI funktioniert derzeit nur auf der 64-Bit-x86-Architektur. ARM64-Support soll bei 4.16 folgen. Die Patches zur Unterstützung von PTI auf 32-Bit-x86-Systemen sind noch in einem frühen Stadium.

Gegenmaßnahmen für die zweite Spectre-Variante

Gegen Meltdown konnte man sich somit bereits schützen, als die Lücken bekannt wurden. Ein Schutz gegen die zweite der beiden Spectre-Varianten folgte erst am 15. Januar mit Linux 4.15-rc8 (1, 2); später folgten noch Korrekturen und Verbesserungen (u. a. 1).

Der Grund für die späteren Gegenmaßnahmen: Erst rund um das Bekanntwerden von Spectre erfuhren die Kernentwickler Details zu den Lücken und möglichen Schutzansätzen. Erschwerend kam hinzu, dass Kernel-Entwickler verschiedener Firmen zwei unterschiedliche Techniken zum Spectre-Schutz einreichten.

[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
(Auch der Spectre-v2-Schutz lässt sich leicht abschalten.)

Der von Intel eingereichte Schutz greift auf die neuen Prozessor-Befehle IBRS, STIBP und IBPB zurück, die Microcode-Updates des Unternehmens nachrüsten. Auf diese greifen die Spectre-Gegenmaßnahmen zurück, die Windows und einige Enterprise-Linuxe integriert haben. Auf älteren Prozessoren soll er größeren Overhead haben, auf Skylake (Core i-6000) und neueren CPUs aber nur wenig.

Ein zweiter Ansatz kam von Spectre-Mitentdecker Google: Kernel-Patches für eine Software-Lösung namens "Return Trampoline" (Retpoline). Sie soll weniger Overhead aufweisen und funktioniert auch ohne neuen Microcode; für umfassenden Schutz erfordert sie jedoch angepasste Compiler, mit denen der Kernel und schützenswerte Anwendungen neu übersetzt werden müssen.

Die Kernentwickler von Linux mussten zunächst die Vor- und Nachteile der beiden Ansätze gegeneinander abwägen; einige dabei im Raum stehende Unklarheiten und Fehlinformationen erschwerten diese ohnehin hektische und leicht chaotische Zeit weiter. Zum Ende der zweiten Januarwoche integrierten die Entwickler dann ein überarbeitetes Retpoline. Das blockt einige der Schwachpunkte, die zur zweiten Spectre-Variante gehören. Ein umfassenderer Schutz erfordert aber ein Kompilieren mit einem Compiler mit Retpoline-Support; Patches, die den nachrüsten, zogen am 16. Januar in den Stable-Zweig der GNU Compiler Collection (GCC) 7 ein.

Der Retpoline-Schutz in 4.15-rc8 ist allerdings nur der Anfang der Gegenmaßnahmen. So folgt für manche Prozessoren vielleicht auch noch die Lösung, die auf den neuen Microcode von Intel zurückgreift. Teile dieses Ansatzes sind ohnehin zur Integration vorgesehen oder bereits enthalten: Sie sind für sicheres Virtualisieren wichtig, damit in mit Linux aufgesetzten VMs auch die neuen Microcode-Funktionen zur Verfügung stehen, die Windows und andere als Spectre-Schutz nutzen. Andere Teile der Microcode-Schutztechnik braucht der Kernel-eigene KVM-Hypervisor zum effizienten Schutz vor Spectre 2; ganz unabhängig davon nahmen die Entwickler auch noch einige Änderungen in Linux 4.15 ein, um die KVM-Virtualisierung besser abzusichern. Auch da steht aber noch mehr im Raum.

Wie bei PTI wird auch der Retpoline-Schutz in Stable- und Longterm-Kernel zurückportiert. Er ist in Linux 4.14.14 und 4.9.77 eingeflossen, die am 17. Januar erscheinen sind. Im parallel veröffentlichten 4.4.112 ist er aber nicht enthalten.

[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
(Die in Linux 4.15 eingeflossenen Spectre-v2-Gegenmaßnahmen sind noch nicht komplett, reduzieren die Gefahr aber schon ein ganzes Stück.)

Spectre-v1-Schutz in Vorbereitung

An Maßnahmen gegen die erste Spectre-Variante schrauben die Entwickler noch. Ähnlich wie Retpoline sind dazu Änderungen bei Kernel und Compilern nötig. Jene für den Kernel werden seit Anfang Januar diskutiert, fließen aber wahrscheinlich nicht mehr in Linux 4.15 ein. Ein Grund für die Trägheit sind Unstimmigkeiten an einigen Stellen. Außerdem ist das ganze aufwendig: Die Entwickler versuchen Codestellen im Kernel zu eliminieren, die gegen die Lücke anfällig sind. Dazu müssen sie den gesamten Kernel-Code nach kritischen Stellen absuchen und auch in Zukunft darauf achten, keine neuen Angriffspunkte einzubauen. Darüber hinaus schrauben die Linux-Entwickler am vom Userspace nutzbaren BPF-Interpreter des Kernels, damit auch darüber ausgeführte Programme keinen Unfug anstellen können.

Aktivieren und Diagnostizieren

Die neuen Schutzmaßnahmen muss man vor dem Kompilieren eines Kernel-Images über die Konfigurationsoptionen CONFIG_PAGE_TABLE_ISOLATION und CONFIG_RETPOLINE explizit einschalten.

[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]
(Der Kernel zeigt im Sysfs an, ob und wie weit das System anfällig für die Lücken ist.)

Über einige unter /sys/devices/system/cpu/vulnerabilities/ zu findende Dateien kann man mit Linux 4.15 prüfen, welchen Lücken den eingesetzten Prozessor betreffen und wie der Kernel dagegen vorgeht. Genau wie die Beschreibung in den vorherigen Absätzen bezieht sich das aber nur auf den Linux-Kernel. Zum umfassenden Schutz gegen die beiden Spectre-Varianten sind darüber hinaus auch Änderungen und Neukompilieren potenziell anfälliger Userspace-Anwendungen nötig. Für Meltdown ist das unnötig, denn das fängt der Kernel komplett ab.

Die erwähnten Gegenmaßnahmen können sich alle auch auf die Performance auswirken. Wie sehr sich das bemerkbar macht, hängt stark vom Prozessor und der verwendeten Linux-Version ab. Zugleich hat aber auch die Anwendung einen großen Einfluss. Auf rechenlastige, die meiste Zeit im Userspace verbringende Programme zeigt sich meist kein Effekt; Wer Kryptogeld mit der CPU schürft, kann sich also beruhigt zurücklehnen.

Auch auf manche Servern – darunter jene hinter Kernel.org – sollen die Schutztechniken keine größeren Einbußen auslösen. Manche Server-Admins berichten hingegen von Performance-Einbrüchen von bis zu 50 Prozent. Das zeigt, wie sehr die Auswirkungen vom Prozessor, der eingesetzten Software und der Workload des Systems abhängen.

Wie stark der Einfluss der Schutztechniken im Kernel ist, können Admins mit dem Kernel-Boot-Parameter nopti und nospectre_v2 testen, denn die legen die Gegenmaßnahmen lahm. Bei einigen mit Meltdown und Spectre-Schutz versehenen Distributionskerneln funktionieren diese Parameter nicht, weil sie andere Lösungen oder älteren Code verwenden. Die nächsten Wochen dürften hier Vereinheitlichung bringen, nachdem die Kernel-Entwickler jetzt Maßnahmen gegen zwei der drei Lücken integriert haben.

Der Tanz zum Schutz vor Meltdown und Spectre ist damit keineswegs beendet; viele weitere Änderungen werden bereits diskutiert. Dabei geht es nicht nur um Feintuning und noch besseres Abdichten, sondern auch größere Optimierungen. So zirkulieren bereits Patches, um PTI bei vertrauenswürdigen Prozessen deaktivieren zu können und so bei ihnen Performance-Einbußen zu vermeiden.

[...]
[ Link nur für registrierte Mitglieder sichtbar. Bitte einloggen oder neu registrieren ]

Der Artikel geht noch erheblich weiter und geht auf zahlreiche weitere Neuerungen ein. Wer da mehr lesen will folge bitte einfach dem Quellenlink.
Wornat1959 ist offline   Mit Zitat antworten
Folgendes Mitglied bedankte sich bei Wornat1959:
bienlein (19.02.18)
Antwort

Themen-Optionen
Ansicht

Forumregeln
Du kannst keine neue Themen eröffnen
Du kannst keine Antworten verfassen
Du kannst keine Anhänge posten
Du kannst nicht deine Beiträge editieren

BB code is An
Smileys sind An.
[IMG] Code ist An.
HTML-Code ist Aus.

Gehe zu


Alle Zeitangaben in WEZ +1. Es ist jetzt 15:58 Uhr.


Sitemap

().