zurück zum Artikel

Die Neuerungen von Linux 4.16

Trends & News | Kernel-Log

Mehr Akkulaufzeit und besserer Schutz vor der Prozessorlücke Spectre sind zwei Highlights des neuen Linux-Kernels. Der integrierte Hypervisor unterstützt jetzt AMDs Speicherverschlüsselung. Außerdem läuft Linux auch als Gast unter einem aus Deutschland vorangetriebenen Hardware-Partitionierer.

In der Nacht auf Ostermontag hat Linus Torvalds die Linux-Version 4.16 freigegeben. Wie jede neue Version der Hauptentwicklungslinie bringt auch die neueste weit über zehntausend Änderungen. Einige rüsten neue Features nach, andere verbessern existierende. Die wichtigsten dieser Neuerungen im Kurzüberblick, bevor der Text auf den folgenden Artikelseiten in die Details geht:

Die Kernel-Entwickler haben den Schutz vor den Anfang Januar bekannt gewordenen Prozessorlücken Spectre und Meltdown verbessert.
Die Kernel-Entwickler haben den Schutz vor den Anfang Januar bekannt gewordenen Prozessorlücken Spectre und Meltdown verbessert.

Das Kernel-Log

Die Artikelserie "Die Neuerungen von Linux" beschreibt regelmäßig die Änderungen neuer Linux-Versionen:

Die folgenden Seiten liefern zahlreiche wichtige Details zu diesen Neuerungen von Linux 4.16 und erläutern zahlreiche weitere. Die letzte Artikelseite enthält zudem einen kleinen Ausblick auf die Änderungen, die 4.17 bringen [26] dürfte.

Längere Akkulaufzeit bei Notebooks mit Intels Mobil-Chips verspricht die neue Option CONFIG_SATA_MOBILE_LPM_POLICY. Anwender und Distributions-Entwickler könenn durch sie gleich beim Kernel-Bau festlegen, inwieweit Linux bei solchen Chips die Stromspartechnik ALPM (ATA Link Power Management) nutzt. Sie senkt die Leistungsaufnahme im Leerlauf oft um rund 1 Watt, wodurch die Akkulaufzeit sparsamer Notebooks schnell mal um eine halbe oder ganze Stunde steigt – manchmal sogar mehr.

git.kernel.org – ebb82e3c79
Die durch ALPM erzielte Einsparung von 1 Watt kann die Leerlauf-Leistungsaufnahme sparsamer Notebooks schnell mal um 10 oder 20 Prozent reduzieren. (Bild:  git.kernel.org – ebb82e3c79 [28])

Dennoch lassen Linux-Distributionen dieses Stromsparpotenzial seit vielen Jahren zumeist links liegen, weil einige der von Linux unterstützten ALPM-Modi zu Datenschäden und anderen Problemen führen. Ein jüngst nachgerüsteter und im Kernel-Log zu Linux 4.15 [29] näher erläuterter Modus zum Device Initiated Power Management (DIPM) verspricht, das zu vermeiden. Der Trick: Der Modus konfiguriert ALPM genau so, wie es Intels Windows-Treiber macht, weil sich das unter Windows im Feldtest bewährt hat.

Bei 4.15 kann man diesen Modus nur via Sysfs wählen. Distributionen könnten DIPM daher leicht über eine kleine Anpassung der Boot-Skripte automatisch aktivieren. Meist dauert es aber Jahre, bis alle Distributoren so etwas umsetzen.

Die neue und im Entwicklungszweig von Fedora 28 bereits erfolgreich getestete Konfigurationsoption verspricht, die Verbreitung zu beschleunigen: Die Kernel-Maintainer der Distributionen können einfach bei der Konfiguration vorgeben, dass DIPM automatisch genutzt werden soll. Die neue Option wirkt sich aber nur auf Notebooks mit Intels Mobil-Chipsätzen [30] aus. Bei Desktop-PCs, Servern und Notebooks mit anderen Chipsätzen muss man die Stromspartechnik daher nach wie vor bei jedem Datenträger manuell aktivieren, indem man med_power_with_dipm in Dateien wie /sys/class/scsi_host/host0/link_power_management_policy schreibt. Wie mit vielen anderen Stromspartechniken geht auch mit dieser ein kleiner Performance-Verlust einher. In den meisten Fällen ist der die Rede aber nicht wert.

Dies war ein schrittweise aktualisierter Artikel

Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen Linux 4.16 zu beschreiben. Zur jüngst erfolgten Freigabe dieser Kernel-Version haben wir die Abschnitte umsortiert und Abschnitte zu wichtigeren Neuerungen an den Anfang gestellt. Von nun an behält der Text seine jetzige Form. Details zur Versionshistorie des Artikels finden Sie am Artikelende [31].

Längere Akku-Laufzeit bei Notebooks verspricht eine kleine Änderung, die eine neue Konfigurationsoption nachrüstet. Anwender und Distributionen können über sie schon beim Kernel-Bau festlegen, dass per USB angebundene Bluetooth-Chips automatisch schlafen gehen, wenn die Möglichkeit dazu besteht. Im Idealfall kann dadurch auch die USB-Hardware in einen sparsameren Modus wechseln, wodurch womöglich auch die CPU tiefer schlafen kann.

Dieses USB Autosuspend für den Bluetooth-Chip muss man bislang manuell oder über Programme wie Powertop oder TLP aktivieren. Die Leistungsaufnahme im Leerlauf sinkt durch die Stromsparfunktion meist um zirka 0,4 Watt, wie der Entwickler erklärt und frühere Messungen im c't-Labor bestätigen. Gerade bei Ultrabooks oder sparsamen Notebooks kann das die Akkulaufzeit signifikant steigern, denn bei optimaler Konfiguration nehmen solche Geräte im Leerlauf oft weniger als 6 Watt auf – ein halbes Watt mehr oder weniger fällt da recht stark ins Gewicht.

Die neue Konfigurationsoption zum Bluetooth USB Autosuspend [33] stammt vom Entwickler, der bei Linux 4.15 [34] und 4.16 [35] auch einige Änderungen an den ATA-Treibern vorgenommen hat, um die Akkulaufzeit von Notebooks zu steigern. Das ist auch das Ziel weiterer Umbauten, auf die er hinarbeitet. Details hierzu finden sich in der Video-Aufzeichnung [36] und den Präsentationsfolien [37] eines Vortrags, den der Red-Hat- und Fedora-Entwickler Anfang Februar auf der FOSDEM gehalten hat [38].

Zum Bau des Kernels muss man jetzt die in Distributionen typischerweise enthaltenen Werkzeuge Flex [40] und Bison [41] einrichten, weil einige damit aufbereitete Dateien den Kernel-Quellen nicht mehr beiliegen, sondern frisch erzeugt werden (u. a. 1 [42], 2 [43]).

Einige Änderungen an Intels Grafiktreiber versprechen, Nutzwert und Alltagstauglichkeit des Supports für Intels Graphics Virtualization Technology (GVT-g) zu steigern. Mit dieser seit Linux 4.8 [46] grundlegend unterstützten Technik kann man virtuellen Maschinen (VMs) Teile des Grafikkerns des Host zuweisen, den das Betriebssystem in der VM ohne viel Overhead wie eine normale GPU nutzen kann. Sprich: Linux oder Windows können aus einer VM die 3D- oder Video-Beschleunigung der Prozessorgrafik nutzen. Bislang gab es aber keinen rechten Weg, um das im Gastsystem per GVT-g beschleunigt erzeugte Bild auch effizient an den Host zu übermitteln. Ein solcher wurde jetzt mit Hilfe der DMA-Buffer-Sharing-Technik Dma_Buf und der Geräte-Überstelltechnik Mdev (Mediated Device Interface) geschaffen, die der Kernel seit Linux 3.3 [47] respektive Linux 4.10 [48] beherrscht (u. a. 1 [49], 2 [50], 3 [51], 4 [52], 5 [53], 6 [54], 7 [55], 8 [56], 9 [57]).

Ohne viel Overhead soll der Host die Bedienoberflächen von VMs lokal darstellen oder an entfernte Systeme schicken können.
Ohne viel Overhead soll der Host die Bedienoberflächen von VMs lokal darstellen oder an entfernte Systeme schicken können. (Bild:  Blog-Beitrag auf 01.org [58])

Durch den neuen Bildweiterleitungspfad kann die Desktop-Oberfläche des Hosts die im Gast erzeugte Bedienoberfläche ohne viel Aufwand integrieren, denn der Host-Compositor kann das Bild ähnlich wie ein normales Anwendungsfenster mit OpenGL handhaben. Der Host kann die Bedienoberfläche der VM auch direkt auf einem seiner Monitorausgänge im Vollbild-Modus ausgeben, was aber vornehmlich für Embedded-Einsatz gedacht zu sein scheint. Darüber hinaus soll der neue Weg auch ein effizientes Übertragen an entfernte Systeme per Spice-Protokoll erlauben. Das ist etwa für eine Virtual Desktop Infrastructure (VDI) interessant, bei der Thin Clients nur die Desktops von Betriebssystemen darstellen, die als VM im Rechenzentrum laufen; das Ganze ist auch für Remote Gaming gedacht, bei dem Spiele in der Cloud laufen. Für solche Einsatzzwecke sind aber noch weitere Umbauten angedacht, denn effizient arbeitet der Spice-Weg bislang nur bei lokalen VMs.

Das Ganze gelingt derzeit mit KVM und einem modifizierten Qemu. Die zuständigen Qemu-Anpassungen stecken noch in der Begutachtungsphase, dürften aber wohl bald in den Entwicklerzweig des System-Emulators einziehen. Daher wird es noch ein Weilchen dauern, bis Linux-Distributionen alles für Intels GVT-g von Haus aus mitbringen. Viele weitere Details zum Ansatz liefert ein Blog-Eintrag [59], den einer der beteiligten Intel-Entwickler verfasst hat.

Einen Performance-Zuwachs bei kleinen I/O-Operationen verspricht einige Umbauten an der Struktur zur Handhabung von Dateien. Die "inode->i_version" genannte Änderung [61] eliminiert nämlich eine durch geänderte Metadaten fällige Schreiboperation, die bislang bei Updates von Nutz- oder Metadaten typischerweise fällig war, obwohl in der Praxis niemand die geänderten Metadaten nutzte.

Der zuständige Entwickler liefert keine Benchmarks mit, um die Vorteile des Umbaus unter Beweis zu stellen; er verweist stattdessen auf eine Warnung eines Constant-Integration-Testsystems [62], bei einem 4k-Schreib/Lese-Test mit XFS und DAX habe der Datendurchsatz um 244 Prozent zugelegt. Bei solchen Ergebnissen gilt aber wie immer: Unter anderen Umgebungsbedingungen mag die Änderung rein gar nichts bewirken.

Die Kernel-Entwickler haben eine Reihe von Umbauten vorgenommen, um die Kernel-intern verwendenten Routing-Strukturen zu entschlacken und so die Performance zu steigern. Das Ganze ist Teil eines Feldzugs gegen Overhead im Netzwerk-Code von Linux, den Netzwerk-Subsystem-Maintainer David S. Miller gerade vorantreibt. Details hierzu finden sich in den Präsentationsfolien [64] und der Video-Aufzeichnung [65] des Vortrags "Linux Networking Dietary Restrictions" [66], den Miller im November auf der Netdev 2.2 gehalten hat. Von diesen und anderen Talks hat LWN.net einige Notizen online [67] gestellt, die Teilnehmer zusammengetragen haben.

Zum Schutz vor der ersten Spectre-Variante (Bounds Check Bypass; CVE-2017-5753) haben die Entwickler nach potenziell für die Lücke anfällige Stellen im Kernel-Code gesucht. Solche haben sie dann geändert, um dort eine spekulative Ausführung zu unterbinden und so die Lücke auszuhebeln. Das gelingt vor allem durch den Aufruf des eigens dafür geschaffenen Makros array_index_nospec() (u. a. 1 [70], 2 [71], 3 [72], 4 [73], 5 [74], Dokumentation [75]).

Die Dokumentation erläutert jetzt Gefahren der spekulativen Ausführung und wie man einige solcher mit einem neuem Makro umgehen kann.
Die Dokumentation erläutert jetzt Gefahren der spekulativen Ausführung und wie man einige solcher mit einem neuem Makro umgehen kann. (Bild:  git.kernel.org – f84a56f73ddd [76])

Womöglich müssen die Entwickler noch mehr Stellen ähnlich anpassen. Außerdem müssen sie bei der Weiterentwicklung darauf achten, das Makro auch bei neuem Code zu nutzen, wenn dieser potenziell anfällige Abschnitte aufweist. Indizien zufolge ist ein Tool in Arbeit, das solche Stellen aufzeigt. Bislang haben einige Entwickler auf das proprietäre Werkzeug Coverity zurückgegriffen, um solche Code-Bereiche zu finden.

Als Maßnahme gegen die zweite Spectre-Variante (Branch Target Injection / BTI; CVE-2017-5715) setzt der Linux-Kernel 4.16 weiter auf Retpoline, das die dritte Seite des Kernel-Log zu Linux 4.15 [78] bereits näher erläutert hat. Dieser Ansatz reicht in einigen Situationen aber nicht aus, etwa bei der Virtualisierung. Hier haben die Kernel-Entwickler nachgebessert: Zum besseren Schutz nutzt der Kernel in einigen Situationen jetzt Funktionen zur Indirect Branch Control (IBC). Das ist der Oberbegriff für die Prozessor-Flags Indirect Branch Prediction Barrier (IBPB), Indirect Branch Restricted Speculation (IBRS) und Single Thread Indirect Branch Predictor (STIBP), die AMD und Intel mit neuem Microcode nachrüsten.

IBC war für Betriebssystemhersteller gedacht, damit sie darüber einen Komplettschutz vor Spectre v2 implementieren. Windows nutzt diesen Ansatz. Auch Red Hat Enterprise Linux, Suse Enterprise Linux und Ubuntu haben anfangs voll auf diesen Schutzansatz gesetzt, den der offizielle Kernel nach jetzigem Stand wohl nie implementieren wird. Mittlerweile sind auch alle drei Distributoren weitgehend oder vollständig auf Retpoline umgestiegen, nachdem die Entwickler des Linux-Kernels dieser Lösung den Vorzug gegeben haben – unter anderem, weil Retpoline deutlich weniger Performance-Overhead als IBC hat und bereits ohne Microcode-Update gut schützt.

Zum sicheren Virtualisieren mit dem Kernel-eigenen Hypervisor KVM reicht Retpoline aber nicht, da es beim Wechsel von einer Virtual Machine (VM) zum Host oder anderen VMs nicht zum Zug kommt. Linux 4.16 verwendet daher an dieser Stelle jetzt die IBC-Funktion IBPB, um diesen Gefahrenpunkt zu eliminieren (u. a. 1 [79], 2) [80]. Außerdem kann der Kernel die Prozessor-Flags jetzt auch an virtuelle Maschinen durchreichen (u. a. 1 [81]). Das ist zum sicheren Virtualisieren von Windows und anderen Betriebssystemen nötig, die ausschließlich mit IBC vor Spectre v2 schützen.

Darüber hinaus greift der Kernel jetzt auch auf IBPB zurück [82], wenn er von oder zu Programmen wechselt (Context Switch), die als "non dumpable [83]" deklariert wurden. Dieses Flag untersagt dem System, beim Programmabsturz ein Abbild des Speicherinhalts (Coredump) zu erzeugen. Es ist daher typischerweise bei Programmen wie GPG gesetzt, die Schlüssel, Passwörter und andere sensitive Informationen verarbeiten – also Programme, die ein lohnendes Angriffsziel sind. Bei solchen nehmen die Kernel-Entwickler daher den Performance-Overhead von IBPB in Kauf, um den Schutz zu verbessern. Linux 4.16 schützt sogar vor Angriffen auf die Firmware, indem es das IBC-Feature IBRS nutzt, bevor er Firmware-Code aufruft [84]. Wenn der Kernel diese beiden Gegenmaßnahmen verwendet, zeigt er in /sys/devices/system/cpu/vulnerabilities/spectre_v2 die Flags "IBPB" und "IBRS_FW" an.

Die Kernel-Entwickler haben den Schutz vor den Anfang Januar bekannt gewordenen Prozessorlücken Spectre und Meltdown verbessert.
Die Kernel-Entwickler haben den Schutz vor den Anfang Januar bekannt gewordenen Prozessorlücken Spectre und Meltdown verbessert.

Der Retpoline ergänzende Schutz mit sporadischer IBC-Nutzung greift naturgemäß nur bei x86-64-Systemen, die IBC durch neuen Microcode gelernt haben. Einige Systemhersteller liefern BIOSe mit solchem Microcode aus. Linux kann den neuen Microcode auch beim Booten in den flüchtigen Speicher des Prozessors laden. Dazu müssen die Archive mit IBC-tauglichem Microcode installiert sein. Die von AMD sind schon seit einigen Wochen Bestandteil vieler Distributionen. Die Archive mit Intels IBC-Microcode sind seit Mitte März verfügbar [86], nachdem das Unternehmen solche schon Anfang Januar vorgestellt hatte, aufgrund von Problem aber wenig später zurückzog [87].

Für IBC und ist wichtig, dass der Microcode früh geladen wird.
Für IBC ist wichtig, dass der Microcode früh geladen wird. (Bild:  git.kernel.org – 42ca8082e260 [88])

Wichtig für IBC: Der Kernel muss das Microcode-Update per "Early Microcode Load" hochladen, damit es im Prozessor aktiv ist, bevor der Kernel selbst richtig in Gang kommt. Die meisten modernen Distributionen nutzen diesen Weg. Einige verwenden aber nach wie vor das klassische und manchmal auch "Late Microcode Load" genannte Verfahren, das den Microcode erst in den Prozessor lädt, nachdem der Kernel schon angelaufen ist und die Fähigkeiten des Prozessors abgefragt hat. Er sieht die vom Microcode-Update nachgerüsteten Prozessor-Flags zur IBC daher womöglich nicht, sodass er die Schutzfunktion dann auch nicht nutzt. Auf diese Problematik weist Linux in den per Dmesg abrufbaren Log-Meldungen jetzt hin [89].

Als wäre das alles nicht schon kompliziert genug, gibt es noch viele andere Details rund um die Gegenmaßnahmen. So ignoriert der Kernel die IBC-Funktionen bei bekanntermaßen problematischen Microcode-Versionen, die auf einer Blacklist stehen [91]; dort waren zeitweise auch Versionen verzeichnet, die Intel letztlich doch wieder als unproblematisch einstufte. Die Liste musste daher bereits mehrfach angepasst werden (u. a. 1 [92], 2 [93]); gut möglich, dass weitere Anpassungen erforderlich werden und Distributionen hier hinterherhinken.

Die Entwicklung der Spectre-v2-Gegenmaßnahmen im Linux-Kernel scheint indes nach wie vor nicht abgeschlossen. Schon im Januar gab es größere Diskussionen darüber, dass Retpoline unzureichend für Prozessoren seit der Skylake-Generation ist, was etwa Intels Core-i-6000-CPUs betrifft. Die Entwickler haben daher Schutzcode extra für solche CPUs integriert. Darüber hinaus haben sie lange über einen deutlich tiefergreifenden Ansatz diskutiert, der den Schutz bei Skylake komplett machen sollte. Von diesem Ansatz und der Problematik war in den letzten Wochen aber nichts mehr zu hören. Warum, ist unklar; möglicherweise sind die Entwickler fürs Erste zu der Auffassung gelangt, dass die jetzigen Gegenmaßnahmen in der Praxis auch auf Skylake allemal ausreichen. Zumindest Red Hat scheint davon aber bislang nicht überzeugt zu sein, denn dessen Unternehmens-Linux verwendet bei Skylake-CPUs nicht Retpoline zum Schutz, sondern allein IBC.

Vor Meltdown (Rogue Data Cache Load/CVE-2017-5754) schützt der Kernel schon seit den zum Jahreswechsel freigegebenen Linux-Versionen per PTI (Page Table Isolation). An diesem ebenfalls im Kernel-Log zu Linux 4.15 [95] näher beschriebenem Ansatz haben die Entwickler zwischenzeitlich einige Detailverbesserungen vorgenommen.

Auch am in 4.15 eingeflossenen Retpoline und anderen Maßnahmen gegen die Anfang Januar bekannt gewordenen Prozessorlücken gab es Feinschliff. Einige verbessern den Schutz, beispielsweise am BPF, um diese von zahlreichen anderen Subsystemen genutzte Virtual Machine des Kernels abzudichten. Einige Umbauten reduzieren auch die Performance-Auswirkungen; gerade die KVM-Performance soll durch einige der Optimierungen wieder zugelegt haben. Wichtig bei der KVM-Virtualisierung ist indes, dass man auch das typischerweise mit KVM genutzte Qemu gegen die Prozessorlücken abdichtet [96].

Details zu diesen und vielen anderen Änderungen rund um den Meltdown- & Spectre-Schutz liefern die Kommentare einiger Git Merges (1 [97], 2 [98], 3 [99], 4 [100], 5 [101], 6 [102], 7 [103]).

Die wichtigsten der verbesserten Gegenmaßnahmen sind auch in aktuelle Stable- und Longterm-Kernel wie 4.15 und 4.14 eingeflossen. Viele sind auch in ältere Longterm-Kernel und die Kernel von Linux-Distributionen für PCs übergegangen. Die Optimierungen stecken aber teilweise nur in 4.16; daher ist der mit dem Schutz vor Spectre und Meltdown einhergehende Performance-Verlust dort in manchen Situationen geringer.

Die unter 64-Bit-x86-Systemen verfügbaren Spectre-v1-Maßnahmen wie array_index_nospec() funktionieren auch auf 32-Bit-x86-Systemen; das gleiche gilt für den Spectre-v2-Schutz Retpoline.

Bei der Meltdown-Gegenmaßnahme PTI ist das nicht der Fall, denn an einer PTI-Implementierung für x86-32-Architektur wird noch gearbeitet. Nachdem eine erste und noch rohe Version Mitte Januar erschien [105], ist seit Anfang März eine vierte Fassung eines PTI für die 32-Bit-x86-Architektur [106] verfügbar. Noch ist unklar, ob diese in Linux 4.17 einfließen wird, denn sie ist bislang nicht im Entwicklerzweig "Linux-Next" angekommen, wo gerade die Änderungen für das im Juni erwartete Linux 4.17 zusammenfließen.

Das für 32-Bit-x86-Systeme vorbereite PTI wird auf PCID-tauglichen Prozessoren zum Einsatz eines 64-Bit-x86-Kernels raten.
Das für 32-Bit-x86-Systeme vorbereite PTI wird auf PCID-tauglichen Prozessoren zum Einsatz eines 64-Bit-x86-Kernels raten. (Bild:  patchwork.kernel.org – 10289935 [107])

Wer ein 32-Bit-x86-Linux auf einem modernen 64-Bit-Prozessor betreibt, kann sich bereits jetzt auf einen größeren Performance-Einbruch durch PTI gefasst machen. Im 32-Bit-Modus kann der Kernel nämlich keine "Process-Context Identifier" (PCID) nutzen, mit denen 64-Bit-x86-Linux die Performance-Einbußen durch PTI deutlich senken kann, sofern der Prozessor denn das seit Intels Haswell unterstützte INVPCID beherrscht. Linus Torvalds und andere wichtige Entwickler raten daher dazu [108], bei solchen Systemen einen 64-Bit-Kernel einzusetzen. Das geht auch ohne Neuinstallation, denn in vielen Fällen funktionieren die Kernel einer 64-Bit-x86-Distribution auch auf deren 32-Bit-x86-Variante.

Allerdings unterstützen die wenigsten Distributionen eine solche Betriebsart von Haus aus, daher muss man oft selbst Hand anlegen. Dadurch kann der Kernel auch andere Prozessor-Features verwenden, die nur im 64-Bit-Betrieb verfügbar ist; zugleich wird der Overhead vermieden, den für 64-Bit kompilierte Programme haben. Dabei kann es aber zu Problemen bei den Schnittstellen kommen, über die sich Kernel und Userspace austauschen. Einige Entwickler sind solche Schwierigkeiten vor ein paar Jahren angegangen; es ist aber unklar, ob sie alles Wichtige abgesichert haben, denn die Kombination von 64-Bit-Kernel mit 32-Bit-Userland ist recht rar und daher kaum getestet.

mail-archive.com – msg1607115
Der 32-Bit-x86-Code soll noch eine Weile im Kernel bleiben. (Bild:  mail-archive.com – msg1607115 [109])

Im Rahmen der PTI-Diskussion kam auch die Frage auf, ob der Support für 32-Bit-x86-Systme entfernt werden sollte. Torvalds meldete sich dazu selbst zu Wort: "In fünf oder zehn Jahren vielleicht. In nächster Zeit aber leider nicht."

Die Spectre-v1-Gegenmaßnahme array_index_nospec() funktioniert auch auf der S390-Architektur sowie modernen 32- und 64-Bit-ARM-Kernen.

Der AMR64-Code von Linux bringt jetzt auch einen Spectre-v2-Schutz mit: Um die Lücke auf betroffenen ARM64-Systemen zu umgehen, springt der Kernel an kritischen Stellen jetzt in die Secure Firmware, damit sie von der Sprungvorhersage (den "Branch Predictor") erzeugte Einträge verwirft. Für die von Meltdown betroffenen ARMv8-Kerne bringt der ARM64-Code von Linux jetzt eine ARM64-Implementation von PTI [111] mit. Details hierzu nennen die Kommentare zwei Git Merges (1 [112], 2 [113]).

Als Spectre-v2-Gegenmaßnahme hat der Code für IBMs Großrechner der S390-Familie jetzt einen "Expoline" genannten Schutz [114], der ähnlich wie Retpoline funktioniert.

Der Code für 32-Bit-ARM-Kerne schützt derzeit nicht vor Spectre v2: Eine Patch-Sammlung, die hier helfen soll [115], hat es bislang nicht in den offiziellen Kernel geschafft. Es gibt auch keinen Meltdown-Schutz, wenn man ein 32-Bit-ARM-Kernel auf einem von Meltdown betroffenen 64-Bit-ARM-Kern betreibt.

Dank des "Virtual Box Guest integration support" braucht man in Zukunft einen Kernel-Treiber weniger installieren und pflegen, wenn man Linux als Gast unter VirtualBox betreibt. Das ist dem Treiber Vboxguest zu verdanken, den ein Red-Hat-Entwickler in den Kernel eingebracht hat, um die Out-of-the-box-Unterstützung für Oracles Virtualisierungslösung zu verbessern. Der Treiber ermöglicht neben Copy & Paste zwischen Host und Gast auch ein Durchreichen von OpenGL-Befehlen; damit kann man die 3D-Beschleunigung der Host-Grafikkarte in VMs nutzen. Der Treiber stellt auch Funktionen für den Seamless-Mode, bei dem einzelne Anwendungsfenster des Gastsystems als autarke Fenster in der Bedienoberfläche des Hosts erscheinen. Damit diese Features arbeiten, muss die im Gast laufendeLinux-Distribution auch die quelloffenen Userspace-Treiber mitbringen, die über den neuen Kernel-Treiber (1 [118], 2 [119], 3 [120]) mit dem Host kommunizieren.

Der Entwickler, der die Integration vorangetrieben hat, hatte bei Linux 4.13 [121] schon den Grafiktreiber Vboxvideo eingebracht, der die von VirtualBox emulierte GPU unterstützt. Dieser liegt allerdings nach wie vor im Staging-Bereich, wo Programmierer versuchen, Code auf Vordermann zu bringen, der die Qualitäts- oder Pflegeansprüche der Kernel-Entwickler bekanntermaßen nicht erfüllt. An der Integration des Treiber Vboxsf, mit dem sich Verzeichnisse des Hosts in Gastsysteme einbinden lassen, arbeitet der Entwickler noch. Letztlich erleichtert die Integration der Gasttreiber aber schon jetzt den Einsatz in VirtualBox deutlich: Wer die Shared-Folder-Funktion nicht benötigt, braucht im Gast jetzt keine Kernel-Module mehr zu kompilieren. Das spart Zeit und vermeidet einige Stolperfallen beim Bau solcher Module, die gerade Linux-Novizen bei ihren ersten Gehversuchen zu Fall bringen.

Whitepaer zur Speicherverschlüsselung von AMD
Bei AMDs SEV verschlüsselt der Prozessor den Speicherbereich jeder VMs mit einem individuellen Key. (Bild:  Whitepaer zur Speicherverschlüsselung von AMD [124])

Der Kernel-eigene Hypervisor KVM kann jetzt die Speicherverschlüsselung nutzen, mit der einige aktuelle AMD-Prozessoren den Arbeitsspeicher von Virtual Machines (VMs) individuell verschlüsseln können (u. a. 1 [125], 2 [126], 3 [127], 4 [128], Dokumentation [129]). Das verspricht mehr Sicherheit in Zeiten von Meltdown und Spectre [130]: In einer VM agierende Angreifer erreichen allenfalls verschlüsselte Speicherinhalte von Host und anderen VMs, wenn sie Sicherheitslücken in Hardware oder Virtualisierungslösung kennen, über die sie sie den gesamten Arbeitsspeicher auslesen können. Das ist vor allem für Cloud-Provider und deren Kunden interessant, bei denen VMs unterschiedlicher Kunden parallel auf einem System laufen. Außerdem sind Kundendaten so auch vor den Mitarbeitern der Cloud-Provider geschützt, denn durch das Ganze kommen auch Admins des Hosts nicht an Speicherinhalte des Gastes. Naturgemäß gilt das alles natürlich nur, solange AMDs Verschlüsselungsfunktion wie dokumentiert arbeitet und selbst keine Lücken aufweist.

Die Verschlüsselungsfunktion in KVM fußt auf der Unterstützung für die AMD-Techniken "Secure Memory Encryption" (SME) und "Secure Encrypted Virtualization" (SEV), die bei Linux 4.14 [131] respektive Linux 4.15 [132] dazustießen und seinerzeit im Kernel-Log schon näher erläutert wurden. Um die von Epyc- und Ryzen-Pro-CPUs unterstützte Technik verwenden zu können, muss allerdings auch die Software angepasst werden, die mit KVM virtualisiert. In der Regel ist das Qemu, das die Speicherverschlüsselung durch einige von AMD vorangetriebene Patches lernen soll [133]. Ferner müssen dann auch noch Bibliotheken wie Libvirt angepasst werden [134], damit darauf aufbauende Software wie Virt-Manager oder Gnome Boxes das Ganze auch anbieten.

Präsentationsfolie eines Vortrags zu Jailhouse
Eine "non-root cell" des über Linux bootenden Jailhouse hat exklusiven Kontrolle über die ihr zugeteilte Hardware. (Bild:  Präsentationsfolie eines Vortrags zu Jailhouse [136])

Der x86-Code von Linux bringt nun alles mit, um als Gastsystem [137] in einer "non root cell" von Jailhouse [138] zu laufen. Dieser maßgeblich von deutschen Siemens-Entwicklern vorangetriebene Hypervisor geht Virtualisierung anders an als KVM, Xen & Co.: Er partitioniert die Hardware in "Zellen", die volle Kontrolle über CPU-Kerne, Arbeitsspeicherbereiche und andere Hardware-Ressourcen erhalten, die ihnen zugeteilt wurden. Das vermeidet den bei klassischer x86-Virtualisierung immanenten Wettbewerb, durch den VMs und Prozesse des Hosts um CPU-Zeit und andere Hardware-Ressourcen konkurrieren.

Die statische Partitionierung der Hardware von Jailhouse isoliert Gäste somit viel besser, was für bestimmte Echtzeit- und Sicherheitsanwendungen interessant oder Voraussetzung ist. Naturgemäß gelingt mit Jailhouse kein Overcommitment, bei der die Summe der VMs zugeteilten Hardware-Ressourcen die tatsächlich vorhandenen Ressourcen übersteigt; dieser Trick kommt häufiger bei der Virtualisierung mit KVM, Xen & Co. zum Einsatz, um das Leistungspotenzial der Hardware besser auszuschöpfen.

Jailhouse ist auf Virtualisierungsfunktionen in der CPU angewiesen und unterstützt ARMv7-, ARMv8- und x86-64-Prozessoren. Jailhouse arbeitet autark, bootet aber mit Hilfe von Linux, das der Hypervisor bei seiner Initialisierung in die "root cell" hievt; dies Linux verliert dann die Kontrolle über Hardware-Ressourcen, die VMs zugeteilt werden.

Eine kleine Änderungen an KVM soll die Performance in bestimmten Situationen deutlich verbessern können.
Eine kleine Änderungen an KVM soll die Performance in bestimmten Situationen deutlich verbessern können. (Bild:  git.kernel.org – 858a43aae236 [140])

Der neue "Paravirtualized TLB Flush" im KVM-Code [141] verspricht einen Geschwindigkeitsgewinn auf Hosts, indem er den VMs mehr CPU-Kerne zuteilt, als tatsächlich im System stecken (Overcommitment).

Einige weitere Änderungen an KVM nennt der Merge Commit [142], der die wesentlichsten Änderungen am Kernel-eigenen Hypervisor gebracht hat. Beim Xen-Support gab es diesmal nur Detailverbesserungen [143].

Linux kann beim Gastbetrieb unter Microsofts Hyper-V jetzt Process-Context Identifiers (PCID) nutzen. Das kann die Geschwindigkeitseinbußen der Meltdown [144]-Gegenmaßnahme PTI (Page Table Isolation) [145] erheblich reduzieren. Damit das gelingt, muss der Hypervisor diese Prozessor-Funktion aber auch zur Nutzung durch Gäste freigeben.

Bei XFS gab es wieder tiefgreifende Umbauten, wie der XFS-Betreuer selbst hervorhebt.
Bei XFS gab es wieder tiefgreifende Umbauten, wie der XFS-Betreuer selbst hervorhebt. (Bild:  git.kernel.org – 20c59c71ae [148])

Die grundlegende Erweiterung von XFS, die im Spätsommer 2016 ihren Anfang nahm, zeigt erste Früchte: Die bei Linux 4.8 [149] integrierte Funktion zum Reverse Mapping (Rmap) in XFS gilt nicht mehr als experimentell [150]; auch das bei Linux 4.9 [151] dazugestoßene Reflink konnte diesen Status ablegen [152]. Um die Features nutzen zu können, braucht es allerdings auch Dateisystem-Werkzeuge, die diese Funktionen freigeben. Aktuelle Versionen der xfsprogs können beide Features beim Formatieren neuer Volumen aktivieren. Standardmäßig machen sie das aber nicht; das dürfte vermutlich erst der Fall werden, wenn noch mehr der grundlegenden XFS-Erweiterungen [153] im Linux-Kernel angekommen sind und die Experimentell-Einstufung ablegen. Zu den noch unfertigen Features zählt das in Linux 4.15 [154] eingeflossene "Online Scrub and Repair", mit dem sich Dateisysteme prüfen und reparieren lassen, ohne sie aushängen zu müssen. Es gab für 4.16 aber allerlei Änderungen, die dieses Feature vorantreiben.

Diese und andere neue Funktionen greifen vielfach auf die Funktionen für Reverse Mapping und Reflink auf. Durch sie kann das Werkzeug cp beim Aufruf mit --reflink beispielsweise Kopien in Sekundenbruchteilen erzeugen, weil sich XFS ein Vervielfältigen der Dateiinhalte sparen kann; stattdessen braucht es dank Reflink-Support nur einen neuen Dateisystemeintrag mit einer Kopie der Metadaten anzulegen, der auf dieselben Nutzdatenbereiche verweist wie der Eintrag der Quelldatei. Änderungen an den Inhalten des Originals wirken sich dennoch ebensowenig auf die Inhalte der Kopie aus wie umgekehrt. Das ist der Unterschied zu einem mit ln erzeugten Hardlink, bei dem man letztlich die gleiche Datei über unterschiedliche Dateisystemeinträge ansprechen kann.

git.kernel.org – 18a5bf2705
RAIDs wieder auseinanderdröseln klingt verrückt, kann laut einem Intel-Entwickler auf manchen NVMe-SSD von Intel aber Vorteile bieten. (Bild:  git.kernel.org – 18a5bf2705 [156])

Über das neue Device-Mapper-Target Dm-Unstripe [157] kann man zu einem JBOD (Just a bunch of disks) oder RAID 0 verbundene Datenträger wieder auseinanderklamüsern und separat ansprechen. Wenn Sie jetzt "was soll denn der Unfug" denken, geht es ihnen genau wie dem Kernel-Log-Autor, als er diese dafür zuständige Änderung sah. Der Commit-Kommentar erklärt aber, wozu das Ganze gut ist. Es soll beispielsweise für NVMe-SSDs von Intel interessant sein, wo verschiedene Controller-Kerne unterschiedliche Speicherbereiche betreuten, die die NVMe-SSD-Firmware zu einem RAID 0 verbindet und komplett exportiert. Das Verbinden bringt aber Overhead mit sich, der etwa zu Latenzen bei Leseanforderungen führt. Für bestimmte Einsatzzwecke kann es daher sinnvoll sein, die Speicherbereiche jeweils separat anzusprechen. Die Firmware erlaubt das aber nicht. Mit dem neuen und von einem Intel-Entwickler eingebrachten Target können Admins diese Beschränkung umgehen.

Das bei Linux 4.12 [158] nachgerüstete "Partial Parity Log for MD RAID 5" (RAID5-PPL) soll nun auch zuverlässig mit Datenträgern arbeiten, bei denen der Write-Back Cache [159] aktiv ist.

Effizienteren Zugriff und dadurch bessere Performance beim Zugriff auf Speicherkarten versprechen Änderungen, durch die das Subsystem für Multi Media Cards (MMCs) nun das Multiqueue Block API nutzt. Diese auch Blk-MQ genannten Infrastruktur kann Datenträger mit mehreren Warteschlangen ansprechen und so stärker von den heute allgegenwärtigen Multicore-Prozessoren profitieren; letztlich ist das nötig, um das Leistungspotenzial moderner Datenträger besser auszuschöpfen.

Gleich mehrere der Umbauten am Device Mapper [160] versprechen, die Performance beim Einsatz auf NVMe-Datenträgern zu verbessern.

Unter einem ganzen Schwung von Änderungen am Block-Layer (1 [161], 2 [162]) waren einige Patches, durch die die IO-Scheduler Deadline [163] und MQ-Deadline [164] auf SMR-Festplatten keine Schreiboperationen mehr eigenständig umordnen. Das ist bei manchen SMR-Platten nötig ("Host Managed") oder für gute Performance empfehlenswert ("Host Aware"), weil diese verschiedene Zonen haben, in denen die Daten enger beieinander liegen als bei klassischen Festplatten. Diese Zonen müssen jeweils sequenziell gefüllt werden; um in einem einmal beschriebenen Bereich neue Daten zu speichern, muss die komplette Zone gelöscht werden.

Einige weitere Änderungen rund um Support für Storage-Hardware finden sich in den Pull-Requests für die Subsysteme Libnvdimm [165], MMC [166], SCSI [167] und SCSI Target [168].

CIFS kommt dank einiger Korrekturen jetzt auch mit per SMB3 angesprochenen Samba- oder Windows-Freigaben klar, bei denen sich die Daten per DFS (Distributed File System) auf verschiedenen Servern verteilen. Ferner bietet CIFS nun experimentelle Unterstützung für SMB3 Direct, mit dem der Client direkt per RDMA (Remote Direct Memory Access) auf dafür vorgesehene Bereiche im Speicher des Servers schreiben oder lesen kann; das vermeidet Overhead auf Client- und Server-Seite und kann so die Geschwindigkeit steigern (u. a. 1 [170], 2 [171], 3 [172], 4 [173]).

Per Overlay-Dateisystem (Overlayfs/Ovl) übereinander gelegte Dateisysteme lassen sich jetzt auch per NFS exportieren (u.a. 1 [174], Dokumentation [175]).

Das NFS-Dateisystem unterstützt jetzt [176] den bei Linux 4.11 eingeführten System-Funktionsaufruf statx(), der eine umfassendere und zugleich aber auch effizientere Abfrage von Datei- oder Verzeichniseigenschaften ermöglicht.

Weitere Änderungen an Dateisystemen und Speicherlösungen nennen die Kommentare der wichtigsten Merge Commits am Code für AFS [177], Btrfs [178], Ceph [179], CIFS [180], Ext4 [181], Fscrypt [182], F2FS [183], GFS2 [184], MD [185], NFS (1 [186], 2 [187]), NFSd [188], Overlayfs [189], UBI/UBIFS [190] und XFS (1 [191], 2 [192]).

Der BPF des Kernel unterstützt jetzt auch Funktionsaufrufe, wie man sie von klassischen Programmiersprachen kennt (u. a. 1 [194], 2 [195], 3 [196]). Solche waren aus Sicherheitsgründen bislang in der manchmal auch eBPF (enhanced Berkeley Packet Filter) genannten Virtual Machine untersagt, mit der XDP (eXpress Data Path), Seccomp, Perf und zahlreiche andere Subsysteme von Linux Programme ausführen, um ihren Aufgaben nachzugehen. Der BPF-Compiler musste daher bislang jegliche Funktionen von BPF-Programmen mittels Inline-Technik an den jeweiligen Stellen einbinden, was die fertigen Programme aufgebläht hat. Die neue Möglichkeit vermeidet das nicht nur, sondern erlaubt zugleich auch ein Erstellen von BPF-Bibliotheken. Auf deren Funktionen können dann verschiedene mit der BPF-VM aufgeführte Programme zurückgreifen, wie man es von anderen Programmiersprachen gewohnt ist.

An frühere Zeiten dürfte sich mancher bei einer anderen Entschlackung erinnern: Die Kernel-Entwickler haben die Unterstützung für "Novell IPX" [197] und das darauf aufbauende Netware Core Protocol File System (Ncpfs) [198] in den Staging-Zweig verlagert. Das soll Anwender warnen, denn diese Funktionen fliegen bald komplett raus, falls niemand den Code übernimmt und aufräumt. Das scheint recht unwahrscheinlich: Beide Techniken kommen heute kaum noch zum Einsatz, denn sie hatten ihre Hochzeit Ende der Neunziger mit Novell NetWare.

Einige weitere Änderungen am Netzwerk-Code nennt der Kommentar des Merge-Commit, in dem das Gros der Änderungen an diesem Subsystem steckt [199]. Unter denen war auch eine Detail-Optimierung am Receiver Autotuning, die die Performance in bestimmten Situationen verbessern kann. Bei einem Benchmark stieg der Durchsatz dadurch von 1700 auf 4600 Mbit/s an [200]; der zuständige Google-Entwickler hatte das verwendete Testszenario aber auch speziell konstruiert, um die Vorteile der Änderung zu demonstrieren.

Mit dem Nouveau-Treiber lassen sich jetzt auch die Beschleunigungsfunktionen von GP108-GPUs [204] nutzen, die bei der GeForce GT 1030 zum Einsatz kommen. Wie dieser Tage üblich, ist dazu eine von Nvidia signierte Firmware nötig, wie sie das Unternehmen über die Linux-Firmware-Sammlung [205] vertreibt; genau wie bei anderen Karten der 900- und 1000-Reihe ermöglicht diese Firmware allerdings keinen Wechsel in die schnellsten oder sparsamsten Betriebsmodi der Grafik-Hardware.

Der Amdgpu-Treiber kann Dank "Multi display synchronization logic [206]" jetzt im Mehrschirmbetrieb die Bildwiederholraten der beteiligten Monitore besser aufeinander abstimmen, was Bildstörungen vermeiden soll. Unter eine Reihe von Detailverbesserungen sind auch allerlei Korrekturen am Support für die Vega-Grafik, die auf Vega-Grafikkarten oder den jüngst vorgestellten Ryzen-Prozessoren mit Grafikkern (Codename "Raven Ridge") zum Einsatz kommt. Wie schon bei 4.15 gab es allerlei Umbauten, um die Unterstützung zum Rechnen auf Radeon-Chips (GPGPU/General-purpose computing on Graphics Processing Units) zu verbessern.

Ein Merge-Kommentar hebt rund fünfzig Änderungen an Grafiktreibern hervor.
Ein Merge-Kommentar hebt rund fünfzig Änderungen an Grafiktreibern hervor. (Bild:  git.kernel.org – 4bf772b14675 [208])

Aus der Reihe "Probleme an Stellen, von denen so mancher nichts ahnt": Beim Asus T100HA und einer Handvoll anderen Convertible-Notebooks erscheint die Textkonsole des Kernels jetzt in der richtigen Ausrichtung, wenn das Tablet auf dem Tastatur-Teil des Systems steckt. In diesen 2-in-1-Geräten steckt nämlich ein Bildschirm-Panel, das standardmäßig für den Porträt-Modus ausgelegt ist; daher muss der Kernel das Bild der Textkonsole im Notebook-Betrieb um 90 Grad drehen. Die dafür zuständigen Kernel-Änderungen schaffen zugleich auch eine Schnittstelle, über die Desktop-Umgebungen erfahren, in welche Richtung sie das Bild drehen müssen (u. a. 1 [209], 2 [210]).

Der bislang vom Amdgpu-Treiber verwendete Scheduler wurde an eine andere Stelle des Direct Rendering Managers (DRM) verschoben [211], weil der für Vivante-Grafikkerne zuständige Etnaviv-Treiber diesen in Zukunft auch nutzen möchte.

Einige weitere Änderungen rund um Grafiktreiber nennen die Kommentare von zwei Git-Merges (1 [212], 2 [213]).

Die Entwickler haben Code in den Bereichen AHCI [215], ASoC [216], HID [217], Grafik, MEI [218], Platform [219] und x86 [220] erweitert, um die Unterstützung für Intels in diesem Jahr erwartete "Cannon Lake [221]"-Prozessoren samt der zugehörigen Chipsätze zu verbessern.

Aas einem Jahr-2038-Problem haben die Entwickler ein Jahr-2106-Problem gemacht.
Aas einem Jahr-2038-Problem haben die Entwickler ein Jahr-2106-Problem gemacht. (Bild:  git.kernel.org – 152194fe9c3f [222])

Dank einer Änderung soll aktuelle 32-Bit-Software Tastatureingaben und andere Input-Events auch nach dem Jahr 2038 noch korrekt verarbeiten können, wenn ein in Unix-Systemen viel genutzter Variablentyp zum Speichern einer Zeitangabe zu klein wird [223]. Das gelingt durch einen Trick mit dem Vorzeichen, der aber nur bis zum Jahr 2106 hilft. Der Commit-Kommentar liefert Details [224] und rät Entwicklern dazu, stattdessen einen anderen Zeitstempel-Typ für Input Events zu nutzen.

Linux unterstützt jetzt das MIPI SoundWire (u. a. 1 [225], 2 [226]), ein Interface zum Datenaustausch mit Audio-Hardware [227], das speziell auf Belange von Mobilgeräten ausgelegt wurde. Support für die in der Kernel-Dokumentation näher erläuterte Technik [228] stammt von Intel-Entwicklern, die auch gleich einen "Intel Soundwire Master Driver [229]" eingebracht haben, der nicht näher spezifizierte Intel-Hardware mit dieser Schnittstelle unterstützt. Ebenfalls neu und gut dokumentiert [230]: Support für den SLIMbus (Serial Low Power Interchip Media Bus) [231]. Dieser stammt genau wie SoundWire von der MIPI (Mobile Industry Processor Interface) und ist zum Verbinden von System-on-Chips (SoCs) mit Audio Codecs gedacht.

Darüber hinaus verbessert eine Reihe neuer und erweiterter Treiber die Hardware-Unterstützung. Exemplarisch einige Beispiele: Der Wacom-Treiber weiß jetzt die zwei Zeichentablets der "One by Wacom"-Reihe anzusprechen [232]. Der Treiber Dib0700 unterstützt jetzt den Xbox One Digital TV Tuner [233]. Neu dabei ist auch Support für den SIOX bus [234] der auf Automatisierungslösungen spezialisierten Firma Eckelmann AG. Der für moderne USB-Chips zuständige Xhci-Treiber implementiert jetzt die Debug Capability (DbC) [235].

Durch diese und weitere Verbesserungen unterstützt Linux 4.16 knapp fünfhundert Geräte oder Geräteklassen mehr als sein Vorgänger; bei rund neunzig davon handelt es sich um PCI/PCIe- oder USB-Geräte, wie die Datenbanken der Linux Kernel Driver DataBase (LKDDb) [236] zeigen.

Details zu diesen und weitere Änderungen rund um Treiber finden sich in den Kommentaren von Git-Merges der Subsysteme ASoC [237], Char [238], Driver Core [239], HID [240], Hardware Monitoring [241], Input [242], Libata [243], Media [244], MFD [245], NTB [246], PCI [247], Platform (1 [248], 2 [249]) RDMA (1 [250], 2 [251]), Sound [252], Staging [253], TTY [254], USB [255] und Watchdog [256].

Neben der Arbeit an den Maßnahmen gegen Meltdown und Spectre gab es noch andere Umbauten, um die Sicherheit von Linux zu verbessern.

Beim Erzeugen einer Konfigurationsdatei zum Kernel-Bau wird jetzt auch bei ARM64- und x86-Systemen standardmäßig die Option STRICT_DEVMEM [258] aktiviert, die einen Zugriff auf den gesamten Arbeitsspeicher via /dev/mem unterbindet. Das empfiehlt sich aus Sicherheitsgründen schon lange; daher setzen Linux-Distributionen die Option bereits seit Jahren. Dass die Standardkonfiguration erst jetzt geändert wurde [259], zeigt eine der Gefahren, die beim unbedarften Konfigurieren eigener Kernel-Images lauern. Hier setzt auch eine andere Änderung an: Der Stack Protector [260] wird automatisch aktiviert, sofern der Compiler [261] die Funktion beherrscht.

Ein Schwung von Änderungen [262] verspricht den per HARDENED_USERCOPY [263] aktivierten Schutz zu verbessern, der den Datenaustausch zwischen Kernel und Userspace absichert; Details hierzu liefert ein LWN.net-Artikel [264] (u. a. 1 [265], 2 [266], 3 [267]).

Das Crypto-Subsystem bringt jetzt einen Treiber für den Platform Security Processor (PSP) mit, der Teil der AMD Secure Processor (AMD-SP) genannten Prozessor-Features von AMD ist (u. a. 1 [268], 2 [269], 3 [270]). Dieser Treiber ist beim individuellen Verschlüsseln des Arbeitsspeichers von virtuellen Maschinen mit AMD SEV involviert, das KVM mit Linux 4.16 [271] lernt.

Der Kernel unterstützt jetzt die ARMv8 Crypto Extensions für Hash-Erzeugung mit SHA-512 und SHA3 [272], die die ARMv8-Standards 8.0 respektive 8.2 definieren.

Auch der Powerpc-Code unterstützt jetzt die bei Linux 4.9 [273] eingeführten "Memory Protection Keys" (Pkeys), mit denen Prozesse die im Arbeitsspeicher hinterlegten Daten effizienter vor unerwünschten Zugriffen schützen können. Durch diese seit GNU C Library (glibc) 2.27 [274] unterstützte Funktion kann ein Verschlüsselungsprogramm beispielsweise sicherstellen, dass nur der Thread den Chiffrierungsschlüssel lesen kann, der ihn auch braucht.

Einige weitere Neuerungen rund um Sicherheit nennen die Kommentare einiger Merges der Subsysteme Crypto [275], GCC-Plugins [276], Integrity [277], Seccomp [278], TPM [279] und User Namespaces [280].

Die Kernel-Dokumentation erläuter jetzt, wie die SPDX-Lizenz-Auszeichnungen zu setzen und zu interpretieren sind.
Die Kernel-Dokumentation erläutert jetzt, wie die SPDX-Lizenz-Auszeichnungen zu setzen und zu interpretieren sind. (Bild:  kernel.org: process/license-rules [282])

Ein zur Kernel-Dokumentation gestoßenes Dokument [283] erläutert, wie die SPDX License Identifier zu verwenden sind. Diese seit Linux 4.14 [284] verstärkt integrierte Kennzeichnung ermöglicht eine skriptgestützte und unmissverständliche Abfrage der Lizenz der Dateien, die den Quellcode enthalten. Mittlerweile tragen rund ein Viertel der Dateien von Linux eine solche Auszeichnung. Um mittelfristig auch Lizenztexte und -Hinweise aus den Quellcodedateien entfernen zu können, haben die Kernel-Entwickler die Lizenztexte jetzt im neu geschaffenen Verzeichnis LICENSES/ [285] zentral hinterlegt.

Die Kernel-Dokumentation erläutert Kernel-Entwicklern jetzt in einem eigenen Dokument [286], wie sie PGP bei der Entwicklung nutzen sollten, um zur Aufnahme eingesandten Code vor Manipulation zu schützen.

Umbauten am Printk-Mechanismus [287] sollen Situationen verhindern, bei denen ein unbestimmter CPU-Kern letztlich vollauf damit beschäftigt wird, per Dmesg abrufbare Meldungen zu verarbeiten. Das passiert vornehmlich auf Systemen mit vielen CPU-Kernen und lässt dem Kernel keine Zeit mehr, die ihm eigentlich aufgetragenen Arbeiten zu erledigen. Details zu dieser Problematik in dieser grundlegenden Infrastruktur erläutert LWN.net [288].

Durch Eingabe von "make snap-pkg" kann man aus den Kernel-Quellen nun auch direkt ein Snap-Paket mit einem eigenen Kernel bauen. Kernel-Snaps kommen derzeit bei Ubuntu Core zum Einsatz; Snap unterstützende Distributionen außerhalb der Ubuntu-Welt kommen mit Kernel-Snaps derzeit meist nicht richtig zurecht.

Der Entwickler Mel Gorman hat eine Reihe von Detailverbesserungen am Scheduler vorgenommen, die die Performance in bestimmten Situationen ein wenig verbessern können (u. a. 1 [289], 2 [290], 3 [291]).

Weitere Änderungen an der Infrastruktur nennen die Merge Commits der Subsysteme Dokumentation (1 [292], 2 [293]), Kbuild (1 [294], 2 [295]), KConfig [296], Kernel Live Patching (KLP) [297], Printk [298], Scheduler (1 [299], 2 [300]).

Das Kommando "perf stat --per-thread" kann die Ausgaben jetzt sortieren, um die größten Ressourcenverbraucher deutlicher hervor zu heben.
Das Kommando "perf stat --per-thread" kann die Ausgaben jetzt sortieren, um die größten Ressourcenverbraucher deutlicher hervor zu heben. (Bild:  git.kernel.org – d8b91dde38f4 [301])

[302] [303]Haufenweise Änderungen gab es auch wieder beim Performance-Analyse-Tool Perf [304] und der von ihr genutzten Kernel-Infrastruktur. Einige von ihnen verbessern beispielsweise die Unterstützung für verschiedene Prozessordesigns von Intel und ARM. Bei Ftrace gab es diesmal nur kleinere Änderungen [305].

Der ARM64-Code kann dank 52-Bit-Adress-Supports [308] jetzt bis zu 4 Petabyte (4096 Terabyte) Arbeitsspeicher adressieren, sofern der verwendete ARM-Kern diese bei ARMv8.2 spezifische Funktion denn implementiert; bislang gelang maximal 48-Bit-Adressierung, daher war bei 256 TByte Schluss [309].

Die Hardware-Monitoring-Treiber lesen jetzt auch die Temperatur des AMD Ryzen Threadripper 1900X [310] korrekt aus.

Einige weitere Änderungen rund um Hardware-nahe Infrastruktur nennen die Kommentare in den wichtigsten Merge-Commits der Codebereiche ACPI (1 [311], 2 [312]), RCU Core [313], DeviceTree (DT) [314], DMA Mapping [315], IOMMU [316], Power Management aka PM (1) [317], 2 [318]), RAS [319], Timer [320], Vhost [321]. Informationen zu den Architektur-spezifischen Änderungen liefern die wichtigsten Merge-Commits am Code für ARM (Core [322], SoC [323], SoC Driver [324], SoC DT [325]), ARM64 (1 [326], 2 [327]), MIPS [328], PPC [329], RISC-V [330], S390 [331], x86 (Cache [332], Platform [333]) und Xtensa [334]. Das sind übrigens nur jene Merges dieser Bereiche, die der Autor aus dem ein oder anderen Grund für erwähnenswert hielt; einige Dutzend andere haben diese Hürde nicht geschafft. Das gleiche gilt auch für andere Aufzählungen dieser Art, die dieser Text enthält.

Mit der Freigabe von Linux 4.16 [336] beginnt zugleich die "Merge Window" genannte Phase, in der Linus Torvalds das Gros der Änderungen für den Nachfolger integriert. In den nächsten Tagen fließen daher viele tausend Änderungen in den Hauptentwicklungszweig von Linux ein, die Entwickler in den letzten Wochen zur Aufnahme in 4.17 vorbereitet haben.

So wollen die Entwickler die bei 4.13 [337] eingeführte TLS-Implementation aufbohren, damit sie auch empfangene Daten im Kernel entschlüsseln kann. Der Treiber Amdgpu soll das bei Linux 4.15 [338] eingeführte Display Core standardmäßig aktivieren. Dadurch werden viele Radeon-Karten der 400er oder 500er-Serie endlich von Haus aus einige Features beherrschen, die zur Ansteuerung moderner Monitore wichtig sind. Umbauten an einem anderen AMD-Treiber versprechen Support, um mit AMDs GPU-Computing-Lösung ROCm [339] auf neueren Radeon-Grafikkarten zu rechnen (GPGPU/General-purpose computing on Graphics Processing Units).

Intels Grafiktreiber soll die GPUs von Cannon-Lake-Prozessoren endlich ordentlich unterstützen. Außerdem wird er den Kopierschutz HDCP (High-bandwidth Digital Content Protection) lernen; er ist für die Wiedergabe geschützter Videos wichtig, denn ohne HDCP geben manche Player die Videos gar nicht oder nur in geringen Auflösungen wieder.

Durch eine größere Aufräumaktion soll der Support für einige Architekturen rausfliegen, die nie größere Bedeutung erlangt haben und von den Herstellern meist aufgegeben wurden. Das betrifft vermutlich Code von acht Architekturen [340] (Blackfin, Cris, Frv, M32r, Metag, mn10300, Score und Tile), um deren Unterstützung in Linux sich meist ohnehin niemand mehr so recht gekümmert [341] hat.

Linus Torvalds beendet das Merge Window typischerweise nach zwei Wochen, indem er die erste Vorabversion einer neuen Kernel-Version veröffentlicht. Das läutet zugleich die Stabilisierungsphase ein, die derzeit fast immer sieben oder acht Wochen dauert. Linux 4.17 erscheint daher wahrscheinlich am 4. oder 11. Juni.

Kernel-
Version
Anzahl
Dateien¹
Zeilen
Quelltext
(Ohne
Doku)²
Entwick-
lungs-
zeitraum
Commits
(Ohne
Merges)³
Diffstat⁴
Linux 4.9 [343] 56.223 22.348.356
(20.520.460)
70 Tage 17.392
(16.214)
11.416 files changed,
713.497 insertions(+),
436.209 deletions(-)
Linux 4.10 [344] 57.202 22.839.659
(20.864.595)
70 Tage 14.249
(13.029)
11.913 files changed,
806.420 insertions(+),
312.218 deletions(-)
Linux 4.11 [345] 57.994 23.137.402
(21.132.076)
70 Tage 13.891
(12.724)
12.528 files changed,
550.108 insertions(+),
252.364 deletions(-)
Linux 4.12 [346] 59.845 24.170.860
(22.125.075)
63 Tage 15.736
(14.570)
12.531 files changed,
1.342.677 insertions(+),
309.204 deletions(-)
Linux 4.13 [347] 60.582 24.767.008
(22.698.219)
63 Tage 14.150
(13.006)
10.898 files changed,
878.431 insertions(+),
282.283 deletions(-)
Linux 4.14 [348] 61.290 25.041.284
(23.050.486)
70 Tage 14.659
(13.452)
23.388 files changed,
719.862 insertions(+),
445.585 deletions(-)
Linux 4.15 [349] 62.303 25.364.802
(23.329.451)
77 Tage 16.223
(14.866)
13.265 files changed,
643.912 insertions(+),
320.289 deletions(-)
Linux 4.16 62.915 25.558.805
(23.495.643)
63 Tagee 14.896
(13.630)
12.239 files changed,
1.133.069 insertions(+),
939.066 deletions(-)
¹ git ls-tree -r --name-only HEAD | wc -l
² find . -type f -not -regex '\./\.git/.*' | xargs cat | wc -l; echo "($(find . -name *.[hcS] -not -regex '\./\.git/.*' | xargs cat | wc -l))"
³ git-log --pretty=oneline vx.(y-1)..vx.(y) | wc -l; echo "($(git-log --pretty=oneline --no-merges vx.(y-1)..vx.(y) | wc -l))"
⁴ git diff --shortstat vx.(y-1)..vx.(y)

Den neuen Linux-Kernel herunterladen und einrichten

Die neue Linux-Version steht wie gewohnt über Kernel.org zum Download [350] bereit. Hinweise zur Einrichtung eines eigenen Kernels finden Sie im Artikel "Linux-Kernel maßgeschneidert [351]". Das darin beschriebene Make-Target make localmodconfig erzeugt weitgehend automatisch eine auf Ihr System zugeschnittene Kernel-Konfiguration, mit der Sie in wenigen Minuten eine neue Linux-Version einrichten können.

Fedora und Rolling-Release-Distributionen wie Arch Linux, Gentoo und OpenSuse Tumbleweed dürften die neue Linux-Version in den nächsten Wochen im Rahmen der regulären Systemaktualisierung erhalten. Bei bereits erhältlichen Releases von OpenSuse Leap, Ubuntu und vielen anderen klassisch gewarteten Distributionen wird das nicht passieren: Bei diesen macht der Kernel normalerweise nur einen Versionssprung, wenn man auf ein neues Release der Distribution wechselt.

Versionshistorie dieses Artikels

Der obige Text wird zwischen Freigabe der ersten Vorabversion und Fertigstellung von Linux 4.16 mehrfach erweitert, um schrittweise alle wichtigen Änderungen der neuen Kernel-Version zu erläutern. Einmal publizierte Absätze ändern oder erweitern wir nur bei triftigen Gründen. Zur Freigabe des neuen Linux stellen wir den Text allerdings um, damit Informationen zu den wichtigsten Neuerungen am Anfang stehen.

[352]

(thl [353])


URL dieses Artikels:
http://www.heise.de/-3964466

Links in diesem Artikel:
[1] #btautosuspend
[2] #alpm
[3] #spectrev1
[4] #spectrev2
[5] #specmelttuning
[6] https://www.heise.de/thema/Meltdown-und-Spectre
[7] #gvgt
[8] #vbox
[9] #sev
[10] #jailhouse
[11] https://www.heise.de/ct/artikel/Linux-4-19-Schoener-starten-und-bereit-fuer-das-WLAN-von-Morgen-4144037.html
[12] https://www.heise.de/ct/artikel/Linux-4-18-freigegeben-Raspi-3-Support-und-Vorboten-neuer-Firewall-Technik-4078605.html
[13] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-17-4061166.html
[14] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-16-3964466.html
[15] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html
[16] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-14-3831941.html
[17] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-13-3771362.html
[18] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-12-3712705.html
[19] #securitymisc
[20] #iversion
[21] #xfs
[22] #network
[23] #inframisc
[24] #gpunvidia
[25] #driversmisc
[26] #outlook
[27] 
[28] https://git.kernel.org/torvalds/c/ebb82e3c79d2a956366d0848304a53648bd6350
[29] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html
[30] https://git.kernel.org/torvalds/c/ebb82e3c79d2a956366d0848304a53648bd6350b
[31] #changelog
[32] 
[33] https://git.kernel.org/torvalds/c/eff2d68ca7388ee1c08811c6bbf4d8587cba01da
[34] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html?#alpm
[35] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-16-3964466.html?#alpm
[36] https://www.youtube.com/watch?v=mypteFGjwH4
[37] https://fosdem.org/2018/schedule/event/hwenablement_improving_linux_laptop_battery_life/attachments/slides/2334/export/events/attachments/hwenablement_improving_linux_laptop_battery_life/slides/2334/improve_linux_laptop_battery_life.pdf
[38] https://fosdem.org/2018/schedule/event/hwenablement_improving_linux_laptop_battery_life/
[39] 
[40] https://www.gnu.org/software/flex/
[41] https://www.gnu.org/software/bison/
[42] https://git.kernel.org/torvalds/c/033dba2ec06c47a9fe1b190bc3281058fb20738d
[43] https://git.kernel.org/torvalds/c/29c833061c1d8c2d1d23a62e7061561eadd76cdb
[44] 
[45] 
[46] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-8-3283402.html
[47] https://www.heise.de/ct/artikel/Kernel-Log-Was-3-3-bringt-4-Treiber-1464001.html
[48] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-10-3596869.html
[49] https://git.kernel.org/torvalds/c/9f31d1063b434c2d54317461d78285b08538c01a
[50] https://git.kernel.org/torvalds/c/e546e281d33d1fc275651aa06f0659045db67e68
[51] https://git.kernel.org/torvalds/c/b851adeac0858c7d257b32eee2142b1519d45ccf
[52] https://git.kernel.org/torvalds/c/a58c38aa6cdf0d00727cafd85cd2354dec46401a
[53] https://git.kernel.org/torvalds/c/ad1d36369b07f6b9db81897802ee5d8764eaa922
[54] https://git.kernel.org/torvalds/c/4023f301d28fb18aac225fef59592a44b9fd42b3
[55] https://git.kernel.org/torvalds/c/e47107ad37c3774be9d5bf6fb4625c59e59f632c
[56] https://git.kernel.org/torvalds/c/e20eaa2382e7888a4e06ccb015c476a6fb1fda0c
[57] https://git.kernel.org/torvalds/c/a03f395ad78f883df490234366dd4e4fc922d174
[58] https://01.org/igvt-g/blogs/wangbo85/2018/sharing-guest-framebuffer-host
[59] https://01.org/igvt-g/blogs/wangbo85/2018/sharing-guest-framebuffer-host
[60] 
[61] https://git.kernel.org/torvalds/c/a4b7fd7d34de5765dece2dd08060d2e1f7be3b39
[62] https://lkml.org/lkml/2017/12/25/8
[63] 
[64] http://vger.kernel.org/~davem/seoul2017_netdev_keynote.pdf
[65] https://www.youtube.com/watch?v=pSaXfQKDCB4
[66] https://www.netdevconf.org/2.2/session.html?miller-datastructurebloat-keynote
[67] https://lwn.net/Articles/738912/
[68] 
[69] 
[70] https://git.kernel.org/torvalds/c/f3804203306e098dae9ca51540fcd5eb700d7f40
[71] https://git.kernel.org/torvalds/c/babdde2698d482b6c0de1eab4f697cf5856c5859
[72] https://git.kernel.org/torvalds/c/2fbd7af5af8665d18bcefae3e9700be07e22b681
[73] https://git.kernel.org/torvalds/c/c7f631cb07e7da06ac1d231ca178452339e32a94
[74] https://git.kernel.org/torvalds/c/edfbae53dab8348fca778531be9f4855d2ca0360
[75] https://git.kernel.org/torvalds/c/f84a56f73dddaeac1dba8045b007f742f61cd2da
[76] https://git.kernel.org/torvalds/c/f84a56f73dddaeac1dba8045b007f742f61cd2d
[77] 
[78] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html
[79] https://git.kernel.org/torvalds/c/20ffa1caecca4db8f79fe665acdeaa5af815a24d
[80] https://git.kernel.org/torvalds/c/15d45071523d89b3fb7372e2135fbd72f6af9506
[81] https://git.kernel.org/torvalds/c/b2ac58f90540e39324e7a29a7ad471407ae0bf48
[82] https://git.kernel.org/torvalds/c/18bf3c3ea8ece8f03b6fc58508f2dfd23c7711c7
[83] http://man7.org/linux/man-pages/man2/prctl.2.html
[84] https://git.kernel.org/torvalds/c/dd84441a797150dcc49298ec95c459a8891d8bb1
[85] 
[86] https://www.heise.de/meldung/Spectre-Luecke-Intels-Microcode-Updates-fuer-Linux-und-Windows-3994347.html
[87] https://www.heise.de/meldung/Meltdown-und-Spectre-Intel-zieht-Microcode-Updates-fuer-Prozessoren-zurueck-3948447.html
[88] https://git.kernel.org/torvalds/c/42ca8082e260dcfd8afa2afa6ec1940b9d41724
[89] https://git.kernel.org/torvalds/c/42ca8082e260dcfd8afa2afa6ec1940b9d41724c
[90] 
[91] https://git.kernel.org/torvalds/c/a5b2966364538a0e68c9fa29bc0a3a1651799035
[92] https://git.kernel.org/torvalds/c/d37fc6d360a404b208547ba112e7dabb6533c7fc
[93] https://git.kernel.org/torvalds/c/1751342095f0d2b36fa8114d8e12c5688c455ac4
[94] 
[95] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html
[96] https://www.qemu.org/2018/02/14/qemu-2-11-1-and-spectre-update/
[97] https://git.kernel.org/torvalds/c/6304672b7f0a5c010002e63a075160856dc4f88d
[98] https://git.kernel.org/torvalds/c/35277995e17919ab838beae765f440674e8576eb
[99] https://git.kernel.org/torvalds/c/d4667ca142610961c89ae7c41a823b3358fcdd0e
[100] https://git.kernel.org/torvalds/c/85a2d939c05965ab9e849735436a3c8d3538dc75
[101] https://git.kernel.org/torvalds/c/7225a442788e20ee108ef2cb97d511375e20acf9
[102] https://git.kernel.org/torvalds/c/ed58d66f60b3dd5b5c9307a65e8cd9b777b55078
[103] https://git.kernel.org/torvalds/c/9e1909b9da04fb582b20d3805e16fad3f6ebf984
[104] 
[105] https://lkml.org/lkml/2018/1/16/668
[106] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1640031.html
[107] https://patchwork.kernel.org/patch/10289935/
[108] https://marc.info/?l=linux-mm&m=151829418201580&w=2
[109] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1607115.html
[110] 
[111] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6aef0fdd35ead88cd651391dcc03562938a7612c
[112] https://git.kernel.org/torvalds/c/0aebc6a440b942df6221a7765f077f02217e0114
[113] https://git.kernel.org/torvalds/c/c0136321924dd338bb8fc5661c4b0e27441a8d04
[114] https://git.kernel.org/torvalds/c/dff839f27dc8d70e191562c8e78b0a9a88028362
[115] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-February/557277.html
[116] 
[117] 
[118] https://git.kernel.org/torvalds/c/0ba002bc4393dcfae031fc707b11c094b46a5048
[119] https://git.kernel.org/torvalds/c/f6ddd094f5793447d594aa9f42032a7aba12b4d2
[120] https://git.kernel.org/torvalds/c/579db9d45cb4e8e7cedff9e6079331a1e2ea9f5d
[121] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-13-3771362.html
[122] 
[123] 
[124] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
[125] https://git.kernel.org/torvalds/c/5dd0a57cf38eeb8b6be1d9c3df9add2f5756d974
[126] https://git.kernel.org/torvalds/c/dc48bae01e5a23ae67758e8fe31cdc439202b190
[127] https://git.kernel.org/torvalds/c/69eaedee411c1fc1cf123520897a96b7cf04d8a0
[128] https://git.kernel.org/torvalds/c/5acc5c063196b4a531a761a954023c1848ec832b
[129] https://git.kernel.org/torvalds/c/b38defdb44fb0377b38896e38ac1fc8482e68f76
[130] https://www.heise.de/thema/Meltdown-und-Spectre
[131] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-14-3831941.html
[132] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html
[133] https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg04107.html
[134] https://www.redhat.com/archives/libvir-list/2017-September/msg00181.html
[135] 
[136] https://wiki.linuxfoundation.org/_media/realtime/events/rt-summit2016/jailhouse_jan-kiszka.pdf
[137] https://git.kernel.org/torvalds/c/4a362601baa6fff92b576d85199f1948cec2fb3b
[138] https://github.com/siemens/jailhouse
[139] 
[140] https://git.kernel.org/torvalds/c/858a43aae23672d46fe802a41f4748f32296518
[141] https://git.kernel.org/torvalds/c/858a43aae23672d46fe802a41f4748f322965182
[142] https://git.kernel.org/torvalds/c/15303ba5d1cd9b28d03a980456c0978c0ea3b208
[143] https://git.kernel.org/torvalds/c/f9f1e414128ea58d8e848a0275db0f644c9e9f45
[144] https://www.heise.de/thema/Meltdown-und-Spectre
[145] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html?meltdown
[146] 
[147] 
[148] https://git.kernel.org/torvalds/c/20c59c71ae711aff845eef640b25935bc9578c9
[149] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-8-3283402.html
[150] https://git.kernel.org/torvalds/c/76883f7988e6d06a97232e979bc7aaa7846a134b
[151] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-9-3351436.html
[152] https://git.kernel.org/torvalds/c/1e369b0e199bbfbab5218e1c1443d839700d8884
[153] https://blogs.oracle.com/linuxkernel/upcoming-xfs-work-in-linux-v48-v49-and-v410,-by-darrick-wong
[154] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html
[155] 
[156] https://git.kernel.org/torvalds/c/18a5bf270532312178145b80c8893614367de10
[157] https://git.kernel.org/torvalds/c/18a5bf270532312178145b80c8893614367de106
[158] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-12-3712705.html?seite=4
[159] https://git.kernel.org/torvalds/c/1532d9e87e8b2377f12929f9e40724d5fbe6ecc5
[160] https://git.kernel.org/torvalds/c/0be600a5add76e8e8b9e1119f2a7426ff849aca8
[161] https://git.kernel.org/torvalds/c/0a4b6e2f80aad46fb55a5cf7b1664c0aef030ee0
[162] https://git.kernel.org/torvalds/c/9454473c9dccb7b9d25e5baf915a082bfd490b33
[163] https://git.kernel.org/torvalds/c/8dc8146f9c92c17caa3c50f979d351c87ed372f8
[164] https://git.kernel.org/torvalds/c/5700f69178e91a6b21250049b86148ed5e9550c1
[165] https://git.kernel.org/torvalds/c/3ff1b28caaff1d66d2be7e6eb7c56f78e9046fbb
[166] https://git.kernel.org/torvalds/c/0bae60fceeab6958ecd56ba5dbb41fb199babec3
[167] https://git.kernel.org/torvalds/c/28bc6fb9596fe1e577d09fc17ee6e1bb051c6ba3
[168] https://git.kernel.org/torvalds/c/858f45bff3b8be61d91e87ef90dddd68433cbffa
[169] 
[170] https://git.kernel.org/torvalds/c/f198186aa9bbd60fae7a2061f4feec614d880299
[171] https://git.kernel.org/torvalds/c/f64b78fd1835d1d764685b0c80c292c5d3daaa07
[172] https://git.kernel.org/torvalds/c/8339dd32fbad71834d61b9103e8884ada9bf3e1c
[173] https://git.kernel.org/torvalds/c/2b6ed88037cf11fadbf74b4a676aed5e1f6f39c3
[174] https://git.kernel.org/torvalds/c/f168f1098dd9038daaf9f7be5f81cdea4985886a
[175] https://git.kernel.org/torvalds/c/a01f64b5c06ca1130b0b72ceb5e2a25e4d37ab08
[176] https://git.kernel.org/torvalds/c/9ccee940bd5b766b6dab6c1a80908b9490a4850d
[177] https://git.kernel.org/torvalds/c/81153336eb76b253ba7852f3f1de525bb98f8c4d
[178] https://git.kernel.org/torvalds/c/31466f3ed710e5761077190809e694f55aed5deb
[179] https://git.kernel.org/torvalds/c/9e95dae76b53e67b64bb8e8468d2285b1dc34720
[180] https://git.kernel.org/torvalds/c/6787dc24b72b88404ae652c914014e51ddf1c4fa
[181] https://git.kernel.org/torvalds/c/23aedc4b9b39428c92b380b386bc97edecb3d4e7
[182] https://git.kernel.org/torvalds/c/3462ac57033e79a87dbae2497773f22b9c536fbc
[183] https://git.kernel.org/torvalds/c/3da90b159b146672f830bcd2489dd3a1f4e9e089
[184] https://git.kernel.org/torvalds/c/26064ea409b4d4acb05903a36f3fe2fdccb3d8aa
[185] https://git.kernel.org/torvalds/c/040639b7fcf73ee39c15d38257f652a2048e96f2
[186] https://git.kernel.org/torvalds/c/efd52b5d363e3e3b6224ad39949219c0df117c91
[187] https://git.kernel.org/torvalds/c/82f0a41e1980318ea4cdae20cdce7b33cb9c8946
[188] https://git.kernel.org/torvalds/c/f1517df8701c9f12dae9ce7f43a5d300a6917619
[189] https://git.kernel.org/torvalds/c/139351f1f98546c312a1942215977ea703b383b8
[190] https://git.kernel.org/torvalds/c/d1de762e36375e1e1cd41f7f93c298ac62d831a7
[191] https://git.kernel.org/torvalds/c/20c59c71ae711aff845eef640b25935bc9578c93
[192] https://git.kernel.org/torvalds/c/e237f98a9c134c3d600353f21e07db915516875b
[193] 
[194] https://git.kernel.org/torvalds/c/ef9fde06a259f5da660ada63214addf8cd86a7b9
[195] https://git.kernel.org/torvalds/c/cc8b0b92a1699bc32f7fec71daa2bfc90de43a4d
[196] https://git.kernel.org/torvalds/c/f4d7e40a5b7157e1329c3c5b10f60d8289fc2941
[197] https://git.kernel.org/torvalds/c/e02554e9a4338c58e75fdfb0ef908a5adc86cba5
[198] https://git.kernel.org/torvalds/c/1bb8155080c652c4853e6228f8f0d262b3049699
[199] https://git.kernel.org/torvalds/c/c3916ad9320eed8eacd7c0b2cf7f881efceda892
[200] https://git.kernel.org/torvalds/c/c3916ad9320eed8eacd7c0b2cf7f881efceda892
[201] 
[202] 
[203] 
[204] https://git.kernel.org/torvalds/c/2c5ac5ba4f855b8cb3f20c52c1a1e0773e671164
[205] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
[206] https://git.kernel.org/torvalds/c/fa2123dbccdc881fae02aaf8b05758db53d62955
[207] 
[208] https://git.kernel.org/torvalds/c/4bf772b14675411a69b3c807f73006de0fe4b64
[209] https://git.kernel.org/torvalds/c/404d1a3edc3873b339198ec3f3d6a09be2ddda4f
[210] https://git.kernel.org/torvalds/c/8d70f395e6cbece665b12b4bf6dbc48d12623014
[211] https://git.kernel.org/torvalds/c/1b1f42d8fde4fef1ed7873bf5aa91755f8c3de35
[212] https://git.kernel.org/torvalds/c/4bf772b14675411a69b3c807f73006de0fe4b649
[213] https://git.kernel.org/torvalds/c/fe26adf431a58d620819618e52a10bf9b5cfde52
[214] 
[215] https://git.kernel.org/torvalds/c/f919dde0772a894c693a1eeabc77df69d6a9b937
[216] https://git.kernel.org/torvalds/c/5fb6e0a1a933cfe13200ae0ae7589263236fa108
[217] https://git.kernel.org/torvalds/c/7103f6b23392c0a57ceba7915f72fa7bf11d2a90
[218] https://git.kernel.org/torvalds/c/f8f4aa68a8ae98ed79c8fee3488c38a2f5d2de8c
[219] https://git.kernel.org/torvalds/c/291101f6a73566f5d1ab597784288c5bc85906fd
[220] https://git.kernel.org/torvalds/c/850eb9fba3711e98bafebde26675d9c082c0ff48
[221] https://www.heise.de/meldung/Core-i3-8130U-Neue-Einstiegs-CPU-fuer-Notebooks-bekommt-Turbo-Modus-3967152.html
[222] https://git.kernel.org/torvalds/c/152194fe9c3f03232b9c0d0264793a7fa4af82f
[223] https://de.wikipedia.org/wiki/Jahr-2038-Problem
[224] https://git.kernel.org/torvalds/c/152194fe9c3f03232b9c0d0264793a7fa4af82f8
[225] https://git.kernel.org/torvalds/c/56d4fe31af77f684bed62fb8201e6327e6ddf4e6
[226] https://git.kernel.org/torvalds/c/9251345dca24b62b14e4e53e6ee3387ae7d9c790
[227] https://www.mipi.org/specifications/soundwire
[228] https://git.kernel.org/torvalds/c/8ecf4264efef64303d6b6c13d35f7c46024fb2ff
[229] https://git.kernel.org/torvalds/c/71bb8a1b059ecd6a070660b7d5d89a7a3c443f4a
[230] https://git.kernel.org/torvalds/c/202318d37613d264e30d71cc32ef442492d6d279
[231] https://git.kernel.org/torvalds/c/3648e78ec701843ff8fab461071ba05067274f26
[232] https://git.kernel.org/torvalds/c/c947218951da68e3fd18a25e9af19556308caf45
[233] https://git.kernel.org/torvalds/c/c4d84547d5ae4fafe2dde649deaf10047ef34d00
[234] https://git.kernel.org/torvalds/c/bbecb07fa0af9a41507ce06d4631fdb3b5059417
[235] https://git.kernel.org/torvalds/c/dfba2174dc421ecad8dc50741054a305cd3ba681
[236] http://cateee.net/lkddb/
[237] https://git.kernel.org/torvalds/c/7590e37bdaeec25ae325f4ba450be13e2aac6c8d
[238] https://git.kernel.org/torvalds/c/f6cff79f1d122f78a4b35bf4b2f0112afcd89ea4
[239] https://git.kernel.org/torvalds/c/47fcc0360cfb3fe82e4daddacad3c1cd80b0b75d
[240] https://git.kernel.org/torvalds/c/183b6366cf473ff0e706a6751adc082faa44843d
[241] https://git.kernel.org/torvalds/c/47d5cc5be396eca67cc89572957ff16f10fd768e
[242] https://git.kernel.org/torvalds/c/eea43ed86f38347979446905a20792a8be7bf5d1
[243] https://git.kernel.org/torvalds/c/76a250f9a5f983c07e0735fac8370a584c520770
[244] https://git.kernel.org/torvalds/c/68c5735eaa5e680e701c9a2d1e3c7880bdf5ab66
[245] https://git.kernel.org/torvalds/c/bc4e118355caf83f472a5d31b850e73adddcf0ab
[246] https://git.kernel.org/torvalds/c/d3658c2266012f270da52e3e0365536e394bd3bd
[247] https://git.kernel.org/torvalds/c/105cf3c8c6264dce4bcdab877feb8037bc4109b1
[248] https://git.kernel.org/torvalds/c/cbd7b8a76b79a2ff6112ef2e77031b694843b8a1
[249] https://git.kernel.org/torvalds/c/cc5cb5af3a3363bc6f0530703895bf9c5fa2f159
[250] https://git.kernel.org/torvalds/c/7b1cd95d65eb3b1e13f8a90eb757e0ea232c7899
[251] https://git.kernel.org/torvalds/c/2246edfaf88dc368e8671b04afd54412625df60a
[252] https://git.kernel.org/torvalds/c/1c1f395b2873f59830979cf82324fbf00edfb80c
[253] https://git.kernel.org/torvalds/c/5d8515bc232172963a4cef007e97b08c5e4d0533
[254] https://git.kernel.org/torvalds/c/db5933225f2fe50d3b91ebbba73ed9c3b703b99a
[255] https://git.kernel.org/torvalds/c/e4ee8b85b7657d9c769b727038faabdc2e6a3412
[256] https://git.kernel.org/torvalds/c/7e6127c1240ed569cdda2a67c8f03836f9f28c05
[257] 
[258] https://cateee.net/lkddb/web-lkddb/STRICT_DEVMEM.html
[259] https://git.kernel.org/torvalds/c/0f7cda2b824bb2afe0d75716a8664117fa03f5e0
[260] https://cateee.net/lkddb/web-lkddb/CC_STACKPROTECTOR.html
[261] https://git.kernel.org/torvalds/c/44c6dc940b190cf22b044a784f3e00a7e7f08b2f
[262] https://git.kernel.org/torvalds/c/617aebe6a97efa539cc4b8a52adccd89596e6be0
[263] https://cateee.net/lkddb/web-lkddb/HARDENED_USERCOPY.html
[264] https://lwn.net/Articles/727322/
[265] https://git.kernel.org/torvalds/c/2d891fbc3bb681ba1f826e7ee70dbe38ca7465fe
[266] https://git.kernel.org/torvalds/c/f7d83c1cf3c77ae45876792aee5285ae970413ac
[267] https://git.kernel.org/torvalds/c/5905429ad85657c28d93ec3d826ddeea1f44c3ce
[268] https://git.kernel.org/torvalds/c/2a6170dfe755b167ca8d6bba2e73695f08b37c54
[269] https://git.kernel.org/torvalds/c/592d5e74ddb28f66c5f4acffcd36156b1621a7c4
[270] https://git.kernel.org/torvalds/c/200664d5237f3f8cd2a2f9f5c5dea08502336bd1
[271] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-16-3964466.html?#sev
[272] https://git.kernel.org/torvalds/c/15d5910e92614e642e7485bb9e89d46e4d1d65d9
[273] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-9-3351436.html
[274] https://www.heise.de/meldung/GNU-C-Library-2-27-unterstuetzt-Memory-Protection-Keys-3960997.html
[275] https://git.kernel.org/torvalds/c/a103950e0dd2058df5e8a8d4a915707bdcf205f0
[276] https://git.kernel.org/torvalds/c/4ed8244ef8847c8ad7414e1a12ba45fef7998721
[277] https://git.kernel.org/torvalds/c/3c29548f87f9545f2f3c1cd1a784fae8ad2d53ba
[278] https://git.kernel.org/torvalds/c/3dbc4f548519f9882676843b4fcdb4e61668baf8
[279] https://git.kernel.org/torvalds/c/ae0cb7be35fe6c7e8bcc816ec4185d0a37748cc1
[280] https://git.kernel.org/torvalds/c/d4173023e63cb85ec02eda02d1789bf078719f00
[281] 
[282] https://www.kernel.org/doc/html/latest/process/license-rules.html
[283] https://git.kernel.org/torvalds/c/aa19a176df95d6e49295d6ff77f7967224c71761
[284] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-14-3831941.html
[285] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/LICENSES
[286] https://git.kernel.org/torvalds/c/b72dde3869fbac36aa95e50fbff4ff006a5125dd
[287] https://git.kernel.org/torvalds/c/dbdda842fe96f8932bae554f0adf463c27c42bc7
[288] https://lwn.net/Articles/737822/
[289] https://git.kernel.org/torvalds/c/7332dec055f2457c386032f7e9b2991eb05c2a0a
[290] https://git.kernel.org/torvalds/c/806486c377e33ab662de6d47902e9e2a32b79368
[291] https://git.kernel.org/torvalds/c/32e839dda3ba576943365f0f5817ce5c843137dc
[292] https://git.kernel.org/torvalds/c/255442c93843f52b6891b21d0b485bf2c97f93c3
[293] https://git.kernel.org/torvalds/c/e03ab6c4ade684bf5d2bf53674440bcb6f476949
[294] https://git.kernel.org/torvalds/c/a659f1598585071eed5c39485840b0f018c9f457
[295] https://git.kernel.org/torvalds/c/9a61df9e5f7471fe5be3e02bd0bed726b2761a54
[296] https://git.kernel.org/torvalds/c/562f36ed28e6faa4245ea2ca1392d90ab98ebbe8
[297] https://git.kernel.org/torvalds/c/e1c70f32386c4984ed8ca1a7aedb9bbff9ed3414
[298] https://git.kernel.org/torvalds/c/ab486bc9a591689f3ac2b6ebc072309371f8f451
[299] https://git.kernel.org/torvalds/c/af8c5e2d6071c71d228788d1ebb0b9676829001a
[300] https://git.kernel.org/torvalds/c/ab2d92ad881da11331280aedf612d82e61cb6d41
[301] https://git.kernel.org/torvalds/c/d8b91dde38f4c43bd0bbbf17a90f735b16aaff2c
[302] 
[303] 
[304] https://git.kernel.org/torvalds/c/d8b91dde38f4c43bd0bbbf17a90f735b16aaff2c
[305] https://git.kernel.org/torvalds/c/27529c891b132f4fc65711334e885f466138ea2a
[306] 
[307] 
[308] https://git.kernel.org/torvalds/c/529c4b05a3cb2f324aac347042ee6d641478e946
[309] https://www.kernel.org/doc/Documentation/arm64/memory.txt
[310] https://git.kernel.org/torvalds/c/6509614fdd2d05c6926d50901a45d5dfb852b715
[311] https://git.kernel.org/torvalds/c/1a9a126b5098160ca934a352617e9e65dbfa679d
[312] https://git.kernel.org/torvalds/c/54ce685cae30c106f062d714c11e644ab1b93b51
[313] https://git.kernel.org/torvalds/c/d772794637451c424729dd71690d7ac158523108
[314] https://git.kernel.org/torvalds/c/2bed26606b61a7b20fc1cc54df53c48c06cd9aa8
[315] https://git.kernel.org/torvalds/c/2382dc9a3eca644147be83dd2cd0dd64dc9e3e8c
[316] https://git.kernel.org/torvalds/c/ef9417e8a903d3a68a83ea2da32f1db030341c37
[317] https://git.kernel.org/torvalds/c/7f3fdd40a7dfaa7405185250974b0fabd08c1f8b
[318] https://git.kernel.org/torvalds/c/a051c14b8db35cb269e9d91e11fc3573b6f7475d
[319] https://git.kernel.org/torvalds/c/a1c75e17e7d1306d35d51d3c330a13f42eba1d2d
[320] https://git.kernel.org/torvalds/c/a46d3f9b1c9888a244ed1ce8da0eca98c3f378e2
[321] https://git.kernel.org/torvalds/c/846ade7dd2e630a309a8c57302046e8c4037b8df
[322] https://git.kernel.org/torvalds/c/367b0df173b0ebea5d18b6971c244e260b5feb17
[323] https://git.kernel.org/torvalds/c/adbc128fa8b4e9ecfdd11d5dd0a7d9845c6ea510
[324] https://git.kernel.org/torvalds/c/fe53d1443a146326b49d57fe6336b5c2a725223f
[325] https://git.kernel.org/torvalds/c/537433b6241e067de2d9da3bed5f4fed9c9eac58
[326] https://git.kernel.org/torvalds/c/0aebc6a440b942df6221a7765f077f02217e0114
[327] https://git.kernel.org/torvalds/c/c0136321924dd338bb8fc5661c4b0e27441a8d04
[328] https://git.kernel.org/torvalds/c/8578953687393945ccb84488973784b9a745b059
[329] https://git.kernel.org/torvalds/c/03f51d4efa2287cc628bb20b0c032036d2a9e66a
[330] https://git.kernel.org/torvalds/c/413879a10b0b0eb563a23c4df896773b2d9413f9
[331] https://git.kernel.org/torvalds/c/dff839f27dc8d70e191562c8e78b0a9a88028362
[332] https://git.kernel.org/torvalds/c/f0b13428c95da67bbf77915e320030d9f18e7fcc
[333] https://git.kernel.org/torvalds/c/669c0f762ed19bd9ec128ebc97ae8641b6e1a4a3
[334] https://git.kernel.org/torvalds/c/d0bd31dc5c0b46b9c778112900cf8f910ac26e1b
[335] 
[336] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1653382.html
[337] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-13-3771362.html
[338] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html
[339] https://rocm.github.io/
[340] https://lkml.org/lkml/2018/3/14/505
[341] https://lwn.net/Articles/748074/
[342] 
[343] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-9-3351436.html
[344] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-10-3596869.html
[345] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-11-3641334.html
[346] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-12-3712705.html
[347] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-13-3771362.html
[348] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-14-3831941.html
[349] https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-15-3900646.html
[350] https://kernel.org/
[351] https://www.heise.de/ct/artikel/Linux-Kernel-massgeschneidert-1402386.html
[352] 
[353] mailto:thl@ct.de