Kernel 4.15 hat den längsten Entwicklungszyklus eines Kernels in den letzten sieben Jahren. Es brauchte neun Release-Kandidaten bis Linus Torvalds, der Herr der Kernel, zufrieden war. So viele RCs benötigte zuletzt Kernel 3.1 im Jahr 2011, der sogar noch einen zehnten Kandidaten brauchte und damit Rekordhalter ist.
Der Grund für den langen Zyklus sind ohne Zweifel Meltdown und Spectre, die die Kernel-Entwickler noch vor den Feiertagen überraschten und einige bis zur Erschöpfung in Atem hielten. Die Art, wie Intel die katastrophalen Sicherheitslücken handhabte war alles andere als hilfreich und Torvalds ließ Intel das auch wissen. Torvalds wünscht sich in seiner Ankündigung einen langweiligen Entwicklungszyklus zu 4.16 ohne neue Überraschungen.
GCC 7.3 aktiviert Retpoline vollständig
Jetzt ist es aber geschafft, 4.15 ist veröffentlicht. Vor wenigen Tagen erschien zudem die GNU Compiler Collection GCC 7.3, die ebenfalls die entsprechenden Switches für Retpoline mitbringt, sodass damit gebaute Distributionskernel über den vollen derzeit verfügbaren Schutz verfügen. Insbesondere 4.16 wird Patches gegen Spectre v1 bringen, aber auch die darauf folgenden Kernel werden noch Nachbesserungen beinhalten. Neben x86 stehen dabei besonders die Plattformen PowerPC und ARM im Fokus.
Meltdown im Griff
Die Kernel Page-Table Isolation-Patches können mit Kernel 4.15 die Meltdown-Lücke schließen. Allerdings kostet das derzeit je nach Anwendung unakzeptable 5 bis 30 Prozent. Für AMD-CPUs bleiben diese Patches deaktiviert, da AMD-Prozessoren für Meltdown nicht anfällig sind. Gegen Spectre v1 haben die Entwickler derzeit noch kein Mittel, daran wird für 4.16 gearbeitet. Spectre v2 lässt sich dagegen zumindest teilweise im Kernel verhindern. In Kernel 4.15 übernehmen das die Retpoline-Patches von Google.
Riesiges Patchset von AMD
Natürlich hat der neue Kernel mehr zu bieten als die Maßnahmen gegen die alles überschattenden CPU-Sicherheitslücken. Herausragend dabei ist die Unterstützung für AMDGPU DC, die es nach mehreren Anläufen in den Mainline-Kernel geschafft hat. Der Kernel unterstützt damit AMDs GPU-Architektur Vega. Dazu zählen die Karten Radeon RX Vega 64 und Radeon RX Vega 56, die jetzt Unterstützung für HDMI 2.0 und Displayport 1.4 bieten. Bei den meisten Karten gilt das auch für Audio. Ebenfalls neu ist die Temperaturüberwachung für AMDs Zen-Prozessoren. Das gleiche gilt auch für den Nouveau-Treiber, der jetzt die Temperaturen bei Nvidias Pascal-Chips beherrscht.
Mit der Unterstützung von Apples ThunderboltIP lassen sich Rechner über die Thunderbolt-Schnittstelle vernetzen. Bei USB-Typ-C-Schnittstellen kann der Port-Manager künftig den Energiebedarf je nach angeschlossenem Gerät regeln. Der Umstieg auf Control Groups v2 ist mit 4.15 vollständig, auch wenn die erste Implementation uns noch lange begleiten wird. Zudem wurden erste Patches für die Unterstützung der neuen RISC-V-Prozessoren aufgenommen.
Das zweiwöchige Fenster für Einreichungen zu Linux 4.16 ist geöffnet, wenn alles glatt läuft, sollte der nächste Kernel Ende März erscheinen. Wie immer bietet die Seite Kernel Newbies eine leicht verständliche Zusammenfassung der Änderungen zu Kernel 4.15.
Bild: „LinuxCon Europe Linus Torvalds“ von Krd Lizenz: CC BY-SA 3.0
Sieben Jahre ist es her, dass ein Kernel einen neunten Release Candidate brauchte um veröffentlicht zu werden. Das war zuletzt Kernel 3.1 im Jahr 2011, der sogar als einziger Kernel 10 Kandidaten brauchte. Mit Kernel 4.15 ist es wieder einmal so weit, dass zumindest ein gestern veröffentlichter 4.15-rc9 nötig wurde. Die meisten Kernel brauchen lediglich sieben Kandidaten um fertig zur Veröffentlichung zu sein. Linus Torvalds schrieb dazu, dass er 4.15 am liebsten veröffentlicht hätte, sich jedoch damit nicht recht wohlfühlte, da auch in der vergangenen Woche noch viele Patches einflossen. Darunter waren unter anderem Aktualisierungen für x86, ARM, MIPS und PowerPC und einige grundlegende Anpassungen der Netzwerk-Architektur.
Bereits Patches für 4.16 eingereicht
Der Grund für die späten Einreichungen ist in der enormen Mehrarbeit zu sehen, die Meltdown und Spectre für die Kernel-Entwickler bedeutet hat. Torvalds geht davon aus, dass kein -rc10 zum Einsatz kommt und somit Kernel 4.15 am 28. Januar erscheint. Einige Entwickler, die diese Woche zur LinuxConf nach Australien reisen haben bereits Patches für Kernel 4.16 eingereicht. Diese werden gespeichert bis das Merge Window, das zweiwöchige Fenster für Einreichungen für den nächsten Kernel, geöffnet wird.
Stand bei Meltdown und Spectre
Mit Kernel 4.15 sollten die Patchsets der Kernel Page-Table Isolation (KPTI) gegen die Sicherheitslücke Meltdown komplett sein. Gegen Spectre in Variante 2 wirkt Googles Retpoline, das aber einen gepatchten GCC benötigt um die Patches wirksam werden zu lassen. Dieser ist zwar verfügbar, aber in den Distributionen mit Ausnahme von Gentoo noch nicht angekommen. Mit -rc9 bleibt den GCC-Betreuern somit noch eine weitere Woche, um GCC 7.3 freizugeben. Bei Spectre in Variante 1 soll die Neuerung IBRS in einem neuen Microcode von Intel helfen. Damit ist Torvalds aber überhaupt nicht einverstanden, wie in einem aktuellen Thread auf LKML nachzulesen ist. Intel versuche hier, so Torvalds mit gewohnt drastischen Worten, ihr hausgemachtes Problem nach unten durchzureichen. Noch ist damit unklar, ob diese Patches für 4.16 angenommen werden.
Nach den Erkenntnissen der letzten Wochen zu Intel ME scheint Intel auch 2018 nicht aus den negativen Schlagzeilen herauszukommen. In einem Blog erschien am 1. Januar ein Artikel, der Hinweise auf einen Fehler sammelte, der anscheinend alle Intel-CPUs der letzten Jahre betrifft. Der Artikel weist zwar einige Fehler und vorschnelle Annahmen auf, folgt aber generell der richtigen Spur. Eine Beseitigung der Sicherheitslücke dahinter ist nur durch teils massive Änderungen an den einzelnen Betriebssystemen möglich, er kann anscheinend nicht in Intels Microcode repariert werden.
Linux- und Windows-Patches vorhanden
Bei Linux sind die Patches teilweise in Kernel 4.15 integriert und weitere für 4.16 geplant. Seit gestern abend ist bereits Kernel 4.14.11 gepatched. Bei Windows wurden sie den Benutzern des Fast Ring bereits im alten Jahr ausgeliefert und sollen an einem der nächsten Microsoft-Patchdays offiziell ausgeliefert werden. Apple schweigt sich wie üblich aus. Aber auch Intel hüllt sich über den Fehler in Schweigen. Die Kommentare in den Patches, die die Sicherheitslücke stopfen, verschleiern die technischen Hintergründe.
Viel geteilter Blogeintrag
Aufmerksam war der Autor des ersten Berichts durch hektisches Treiben bei den Kernel-Entwicklern in den letzten Wochen und über die Feiertage geworden. Tiefgreifende Änderungen am Virtual-Memory-Subsystem des Kernels, die ansonsten oft über Monate und Jahre diskutiert werden, bevor eine Zeile Code einfließt, brauchten nur wenige Wochen um in Kernel 4.15 einzufließen, der vermutlich in zwei Wochen veröffentlicht wird.
Hektik bereits seit Oktober
Der entsprechende Bug hat derzeit den Status embargoed, was bedeutet, dass betroffene Institutionen Kenntnis davon haben, der Fehler aber noch nicht veröffentlicht ist. Die zugrundeliegende Sicherheitslücke und die seit Oktober einfließenden Patches wurden zuerst am 20. Dezember auf LWN näher gewichtet. Der dortige Artikel ist derzeit aber nur für Abonnenten zugänglich und wird erst in den nächsten Tagen freigegeben.
Torvalds lässt Patches für 4.15-rc4 zu
Linus Torvalds hatte sich zu den sogenannten KAISER-Patches, die seitdem in KPTI für Kernel-Page-Table-Isolationumbenannt wurden, am 27. November dahingehend geäußert, er würde die Patches lieber in 4.16 sehen, wies aber auch gleich auf die Notwendigkeit der Portierung in die zurückliegenden LTS-Kernel 4.9 und 4.14 hin. Trotzdem flossen in 4.15-rc4 vorbereitende Patches ein, der Großteil wird, der gebotenen Sorgfalt bei solch tiefgreifenden Änderungen geschuldet, erst mit 4.16 ausgeliefert.
Künftig getrennte Page-Table-Bereiche
Was steckt nun hinter dem ganzen geschäftigen Treiben? Die Kernel-Entwickler trennen damit strikt die Page Tables, die derzeit noch von Kernel- und User-Space gemeinsam genutzt werden, in zwei völlig getrennte Sätze auf. Damit wollen sie verhindern, dass ein unprivilegierter Prozess auf den Speicherbereich im Kernel-Space zugreifen kann. Nach bisherigem Erkenntnisstand kann ein Prozess eine Intel-CPU durch Ausnutzen der Sicherheitslücke dazu bringen, Speicherbereiche zu prefetchen und dann durch Aushebeln der Zugriffskontrolle direkten Zugriff auf den Kernel-Bereich zu erhalten. Zudem könnte auch der Sicherheitsmechanismus ASLR ausgehebelt werden. Die auslösenden Prozesse können von normalen Anwendungen wie Office-Anwendungen bis hin zum JavaScript in Web-Browsern stammen. Im schlimmsten Fall könnten manipulierte Anwendungen oder Anwender den Kernelspeicher auslesen, der alle möglichen Geheimnisse wie Passwörter und weitere Zugangsdaten enthalten kann. Stellt man sich das auf öffentlichen Cloud-Servern vor, wird das mögliche Ausmaß klar.
Systemaufrufe bald langsamer
Wenn eine Anwendung in eine Datei schreiben oder eine Netzwerkverbindung öffnen will, muss sie dazu vorübergehend die Kontrolle über den Prozessor an den Kernel abgeben. Um den Übergang vom User-Modus in den Kernel-Modus und zurück so schnell und effizient wie möglich zu gestalten, hat der Kernel Zugriff auf den virtuellen Adressraum aller Prozesse, obwohl dieser für die Anwendung unsichtbar ist. Wenn der Kernel benötigt wird, führt das Programm einen Systemaufruf (syscall) durch, der Prozessor wechselt in den Kernel-Modus und hat Zugriff auf den Kernel. Wenn das erledigt ist, wird die CPU aufgefordert, in den Benutzermodus zurückzukehren und den Prozess erneut zu starten. Im Benutzermodus bleiben der Code und die Daten des Kernels für die Anwendung unsichtbar, ist aber in den Page Tables des Prozesses vorhanden.
AMD vermutlich nicht betroffen
Diese Sicherheitslücke ist in hohem Maße für virtuelle Maschinen und Container relevant, wo Bereiche mit Kernel-Techniken isoliert werden und ein Ausbrechen daraus kritisch sein kann. Nach Angaben des Kernel-Entwicklers Thomas Lendacky, der bei AMD beschäftigt ist, sind AMD-CPUs nicht betroffen. Er schreibt dazu auf LKML: » Die AMD-Mikroarchitektur erlaubt keine Speicherreferenzen, einschließlich spekulativer Verweise, die auf höher privilegierte Daten zugreifen, wenn sie in einem weniger privilegierten Modus ausgeführt werden, wenn der Zugriff zu einem Seitenfehler führen würde.«
Mindestens 5 Prozent Strafe
Also kann, wenn sich das bewahrheitet, für AMD-Prozessoren der KPTI-Patchset entfallen. Das könnte sich als Wettbewerbsvorteil herausstellen, da mit der Trennung der Page Tables ein anwendungsabhängiger Performance-Verlust von derzeit geschätzten mindestens fünf Prozent einhergeht. Diese Geschwindigkeitseinbußen entstehen dadurch, dass pro Syscall-Kontextwechsel ein TLB-Flush notwendig wäre. In Phasen ohne Syscall soll der TLB weiter wie gewohnt arbeiten. Modernere Intel-CPUs können dem TLB-Flush mit der PCID-Technik etwas entgegenwirken. Auf Phoronix gibt es erste Benchmarks dazu.
Des Pudels Kern?
Eines der Schlüsselwörter in der Aussage von Lendacky ist »spekulative Referenzen«. Bereits bei der Durchsicht der ursprünglichen KAISER-Patches von Sicherheitsforschern der Universität zu Graz stellte der Reviewer Anders Fogh in seinem Bericht fest: »Meine Ergebnisse zeigen, dass die spekulative Ausführung trotz Verstößen gegen die Isolation zwischen Kernel- und Benutzermodus tatsächlich weiter ausgeführt wird.« Hier könnte nach heutiger Erkenntnis der auslösende Fehler in Intels Silizium liegen.
Intel schweigt
Im Moment ist vieles an dieser Sicherheitslücke noch recht spekulativ, vor allem fehlen Informationen von Intel selbst. Klar ist, dass die Lücke besonders im Unternehmensumfeld ausgenutzt werden könnte. Große Cloud-Anbieter wie Amazon und Microsoft Azure haben bereits kurzfristig Wartungsmaßnahmen und Reboots angekündigt, ohne dabei jedoch ein mögliches Problem zu erwähnen.
Klar scheint auch zu sein, dass der Patch erst beim Booten aktiviert wird und somit AMD-CPUs von dem Performance-Verlust nicht betroffen sein werden. Unklar ist noch, wie weit genau die Lücke bei Intel-CPUs zurückreicht. Bisher sieht es aber so aus, als seien mindestens alle Intel-CPUs der letzten zehn Jahre betroffen.
Trotzt der Thanksgiving-Feiertage in den USA wurde das Zeitfenster für Einreichungen zu Kernel 4.15 eingehalten. Nach zwei Wochen, in denen Entwickler ihre Patches einreichen konnten, hat Linus Torvalds nun Kernel 4.15-rc1 freigegeben, der über die nächsten Wochen bis in den Januar 2018 stabilisiert wird. Torvalds bedankt sich bei den Entwicklern dafür, dass sie größtenteils seiner Maßgabe gefolgt sind und ihre Patches in der ersten Woche des Merge-Window eingereicht hatten und damit seinen Urlaub in der zweiten Woche weniger arbeitsintensiv gestalteten.
Mehr Änderungen als zu 4.14-rc1
Die Patches für 4.15-rc1 sind recht umfangreich. Bis gestern liefen fast 13.500 Einreichungen auf, die über 580.000 neue Codezeilen bedeuten und Änderungen an fast 12.000 Dateien bewirken. Gleichzeitig wurden über 270.000 Zeilen Code entfernt. Derzeit besteht der Kernel aus 62.285 Dateien mit über 25.350.000 Zeilen Code. Damit umfasst er rund 1.000 Dateien mehr als noch Kernel 4.14.
AMDGPU DC umfasst 130.000 Zeilen
Der Großteil des hinzugekommenen Codes ist AMDGPU DC zu verdanken. Der neue Display-Stack für den AMDGPU DRM-Treiber umfasst über 130.000 Zeilen Code. Damit werden AMDs Vega-GPUs endlich unter Linux gut unterstützt. Auch einige weitere, auch ältere Radeon-Karten profitieren von den AMD-Patches, die zu Ende bringen was bei AMD vor fast zwei Jahren als DAL begann und dann zu DC umbenannt wurde.
Intel und Nvidia
Weitere Änderungen im Grafikbereich gab es für Intels »Coffee Lake Graphics«. Der neue Kernel wird Core-i-8-Prozessoren der Coffe-Lake-Generation direkt unterstützen. Für den freien Treiber Nouveau für Nvidias Grafikkarten wurde die Speicherverwaltung überholt. Auch die Grafiktreiber für den Raspberry Pi wurden erneut verbessert.
Control Groups 2
Eine wichtige Änderung betrifft die Control Groups. Hier wurde die zweite Version der Control Groups jetzt komplettiert. Die RISC-V-Architektur wird anfänglich unterstützt, auch wenn es noch eine Weile dauern wird, bis sie durch entsprechende Treiber praktisch nutzbar ist. Besitzer von NVMe-Laufwerken können sich auf potentiell mehr Geschwindigkeit freuen, denn der Blocktreiber für NVMe wurde um Multipath erweitert. ThunderboltIP ist eine weitere interessante Neuerung, erlaubt sie es doch, Netze per Thunderbolt-Kabel zu erstellen. Aus dem aktuellen Kernel entfernt wird das Open Sound System (OSS), das heute kaum mehr Rolle mehr spielt.
