zurück zum Artikel

Die neue Kernel-Version bringt Speicherverschlüsselung, einen neuen Schlafmodus und einige Performance-Verbesserungen. Außerdem überwindet sie eine Grenze, die auf die ersten 64-Bit-x86-Prozessoren zurückgeht.

Linus Torvalds hat die Linux-Version 4.14 freigegeben. Wie seine Vorgänger wartet auch der neue Kernel mit zahlreichen Neuerungen auf. Diesmal ist keine dabei, die so richtig herausragend ist; es gibt aber gleich mehrere, die ihr Potenzial erst langfristig oder bei genauerem Hinsehen offenbaren. Die wichtigsten Verbesserungen im Kurzüberblick:

• Linux 4.14 ist trotz kleinerer Auffälligkeiten und Ungereimtheiten bei der Entwicklung ein Longterm Kernel. Er wird daher nicht nur zwei bis drei Monate mit Korrekturen und kleineren Verbesserungen versorgt, sondern mindestens zwei Jahre [2].

• Eine neue Debugging-Funktion [3] verspricht einen indirekten Geschwindigkeitszuwachs, denn sie weist weniger Overhead auf als ein bislang häufig verwendeter Mechanismus.

• Linux 4.14 nutzt auf einigen Notebooks einen Suspend-to-Idle genannten Bereitschaftsmodus [4], der sich durch flotteres Aufwachen vom traditionell verwendeten Suspend-to-RAM abhebt.

• Die Kernel-Entwickler geben ein bei der x86-64-Einführung noch in weiter Ferne scheinendes Limit an, damit Linux nicht nur 64, sondern bis zu 4096 Terabyte (4 Petabyte) Arbeitsspeicher ansprechen [5] kann.

• Linux 4.14 unterstützt die Speicherverschlüsselung [6], die einige der jüngst eingeführten AMD-Prozessoren beherrschen.

• Der Kernel kann jetzt im Speicherbereich von Programmen liegende Daten versenden, ohne diese zuerst kopieren zu müssen [7]; dieser Zerocopy-Ansatz reduziert den Overhead und soll so die Performance steigern.

• Neu dabei ist auch ein seit Jahren entwickeltes Framework, mit dem Entwickler die Arbeitsspeicherbereiche leichter, flexibler und schneller nutzen [8] können, die unter der Ägide von Hauptprozessor, Grafikprozessor, Krypto-Beschleunigern und ähnlicher Hardware stehen.
  

• Btrfs und SquashFS können Daten jetzt mit Zstd packen [9]. Laut dem zuständigen Entwickler kann dieser Algorithmus ähnlich schnell komprimieren wie LZ4 und bei der Packdichte zugleich eine Qualität erzielen, die an jene von LZMA heranreicht.

Das Kernel-Log

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

• Linux 5.6 (30. März 2020) [10]
• Linux 5.5 (27. Jan. 2020) [11]
• Linux 5.4 (25. Nov. 2019) [12]
• Linux 5.3 (16. Sep. 2019) [13]
• Linux 5.2 (8. Juli 2019) [14]
• Linux 5.1 (6. Mai 2019) [15]
• Linux 5.0 (4. März 2019) [16]
• Linux 4.20 (24. Dez. 2018) [17]

• Optimierungen am Ext4- und Quota-Code [18] versprechen, die Menge der pro Sekunde erzeugten Dateien teilweise drastisch zu steigern.

• Unter einer Reihe von Techniken zum Steigern der Systemsicherheit ist ein Schutz gegen Angreifer [19], die sensitive Arbeitsspeicherinhalte durch Neustart mit einem eigenen Betriebssystem abzugreifen versuchen.

• Die Kernel-Entwickler haben einige GCC-Plug-ins verbessert [20], um es Angreifern noch schwerer zu machen, zur Rechteausweitung dienliche Stellen im Code zu finden.

• Eine ganze Reihe neuer und überarbeiteter Treiber für Grafikprozessoren [21] und andere Geräte [22] verbessern Hardware-Support und Performance.

• SPDX-Auszeichnung im Quellcode [23] sollen helfen, Lizenzverletzungen zu vermeiden.

• Ein Statement in der Dokumentation soll Firmen bei der Abwehr von Copyright-Trollen [24] helfen. Damit versuchen die Kernel-Entwickler das vorgehen eines früheren Kernel-Entwickler zu unterminieren, der schon mehrfach in Deutschland vor den Kadi gezogen ist.

Die folgenden Seiten liefern Details zu diesen und zahlreichen weiteren Neuerungen von Linux 4.14; die wichtigsten Änderunen eines beschriebenen Bereichs finden sich am Anfang der jeweiligen Artikelseiten. Auf der letzten Seite findet sich zudem ein kleiner Ausblick auf die Neuerungen, die 4.15 [25] bringen dürfte.

Performance-Zuwachs, anders Schlafen & mehr Speicher ansprechen

[26]Indirekte Performance-Steigerung durch ORC

Zu einer der wichtigsten Änderungen von 4.14 zählt der ORC Stack Unwinder, der einen weiteren Weg zur Erzeugung besser lesbarer Stacktraces stellt. ORC ist aber keineswegs nur für Entwickler relevant, die bei einem Kernel-Fehler die Namen der Funktionen sehen wollen, über die der Kernel-Code zum Fehlerpunkt gelangt ist. Der neue Analyseweg zum Aufschlüsseln von Call Traces verbessert indirekt auch die Performance bei der alltäglichen Nutzung, denn er braucht keine Frame Pointer, die den Kernel größer und langsamer machen – Fedora, Ubuntu und einige andere Distributionen aktivieren diese aber derzeit nichtsdestotrotz, damit der Frame Pointer Unwinder des Kernels die Call Traces aufschlüsselt. Laut einem Commit-Kommentar [27] kann ein Umstieg auf ORC daher die Performance um 1 bis 3 Prozent steigern; bei besonders Kernel-lastigen Aufgaben können es sogar zwischen 5 und 10 sein, wie auch der Hilfetext zum neuen Unwinder [28] erwähnt.

ORC steht für "Oops Rewind Capability". Das von ihm genutzte Format ist eine vereinfachte Version von DWARF, dem unter Linux meistgenutzten Format für Debugging-Informationen. Beide Formate sind für Binaries gedacht, die im bei Linux gängigen Executable and Linkable Format (ELF) vorliegen.

Die Performance-Steigerung war aber nicht der Hauptgrund zur Entwicklung von ORC; vielmehr wollten die Programmierer einen Stack Unwinder schaffen, der verlässlicher arbeitet als der Frame Pointer Unwinder. Dadurch soll ORC dann letztlich Kernel Live Patching (KLP) robuster und flexibler machen; auch Profiler profitieren vom neuen Ansatz. ORC dürfte aber noch etwas Feintuning brauchen, bevor Distributoren darauf umsteigen. Weitere Details zu diesen und anderen Aspekten von ORC erläutern ein Blog-Eintrag eines Entwicklers [29], ein LWN.net-Artikel [30], die Kernel-Dokumentation [31] sowie die Kommentare und Inhalte einiger Commits (u. a. 1 [32], 2 [33], 3 [34], 4 [35], 5 [36]).

[37] [38]Viel mehr Speicher ansprechen

Der x86-64-Architekturcode von Linux kann jetzt bis zu 4096 Terabyte (4 Petabyte) Arbeitsspeicher adressieren; Programmen steht sogar ein virtueller Adressraum von 128 Petabyte bereit. Bislang war bei 128 Terabyte virtuellem Adressraum und 64 Terabyte physischem Speicher Schluss – letztgenanntes Limit erreichen einige Hardware-Hersteller gerade mit ihren stärksten Systemen.

Mit aktuellen Prozessoren ist da aber weiter Schluss, denn die zur Adressierung von mehreren Petabyte Arbeitsspeicher zuständigen 5 Level Pages Tables [40] erfordern eine CPU mit einer "LA57" genannten Technik. Laut den Commit-Kommentaren will Intel diese Funktion bei zukünftigen Prozessoren implementieren, anfangs womöglich nur bei einzelnen und teuren Modellen der Xeon-Baureihe. Die bei LWN.net näher erläuterten 5 Level Pages Tables [41] harmonieren derzeit auch noch nicht mit Xen, wohingegen KVM die Technik bereits unterstützt (u. a. 1 [42], 2 [43]).

[44] [45]Schlafen wie Android

Einige moderne Notebooks steuern mit 4.14 nicht mehr Suspend-to-RAM (aka STR oder ACPI S3) an, wenn sie diese in den Bereitschaftsmodus schicken. Vielmehr schlafen sie per Suspend-to-Idle, aus dem die Geräte viel schneller aufwachen – zugleich ist die Leistungsaufnahme in diesem Schlafzustand aber höher; daher belastet er den Akku stärker.

Das Ganze betrifft etwa das mit Linux und Windows erhältliche Ultrabook Dell XPS 13 (9360), aktuelle Surface-Notebooks von Microsoft und einige andere Laptops, die zumeist besonders sparsame Prozessoren enthalten und zu den teuren Modellen zählen. [Update 20171110-10:00]Das erwähnte XPS-Ultrabook bleibt vorerst doch außen vor [47], weil Probleme gefunden wurde.[/Update]. Im Windows-Betrieb wechseln diese Notebooks standardmäßig in einen Stromsparmodus, den Microsoft "Modern Standby" nennt, die Linux-Welt aber Suspend-to-Idle (abgekürzt S2I oder S2Idle). Diesen seit Linux 4.10 [48] unterstützten Schlafzustand nutzt der Kernel bei solchen Notebooks jetzt automatisch [49]. Ein Grund dafür: Hersteller testen vielfach nur den standardmäßig genutzten Schlafmodus mit dem beigepackten Betriebssystem. Bei Geräten mit Modern Standby bleiben dadurch Fehler in den Codepfaden der Firmware unentdeckt, die sich um Suspend-to-RAM kümmern. Dieser traditionell für den Bereitschaftsmodus genutzte Schlafzustand arbeitet auf Suspend-to-Idle-Geräten daher manchmal unzuverlässig oder gar nicht.

Notebooks wachen aus dem Suspend-to-Idle meist sehr schnell auf, sodass sie voll einsatzbereit sind, sobald man das Display aufgeklappt und die Hände auf die Tastatur gelegt hat. Das gelingt, weil Suspend-to-Idle die Komponenten eines Systems lediglich mit den zur Laufzeit nutzbaren Schlafmodi so tief wie möglich schlafen legt. Android-Geräte nutzen solch einen Ansatz schon lange. WLAN-Verbindungen bleiben beim Suspend-to-Idle erhalten; daher muss man auch nicht auf eine Neuanbindung ins Internet warten. Die Leistungsaufnahme im Schlafzustand ist bei diesem Ansatz allerdings höher als beim Suspend-to-RAM. Schließlich erhalten bei ihm nur der Arbeitsspeicher und einige zum Wecken benötigte Komponenten noch Strom.

Windows-Anwender müssen sich mit dem höheren Stromverbrauch im Schlafzustand abfinden, denn Windows wechselt immer in den Schlafzustand, den die Firmware vorgibt. Mit Linux kann man Suspend-to-RAM hingegen auch auf Suspend-to-Idle-Notebooks nutzen: Sie müssen lediglich deep in /sys/power/mem_sleep schreiben, damit das System beim Wechsel in den Bereitschaftsmodus wieder ins Suspend-to-RAM geht. Falls Sie später wieder Suspend-to-Idle verwenden wollen, schreiben Sie s2idle in die Pseudodatei.

[51]Rolle Rückwärts bei der Taktfrequenzangabe in /proc/cpuinfo

Kurz vor Veröffentlichung von Linux 4.14 haben die Entwickler die im Kernel-Log zu Linux 4.13 [52] hervorgehobene Änderung revidiert, durch die /proc/cpuinfo auf x86-Systemen nur noch den Basistakt des Hauptprozessors ausgab (1 [53], 2 [54]). Stattdessen liefert die Zeile "cpu MHz" jetzt wieder eine grob berechneten Mittelwert, der von den Taktfrequenzstufen abgeleitet wird, in denen die Prozessorkerne kurz vor der Abfrage liefen. Eine Reihe von Anwendern hat sich dieses Verhalten zurückgewünscht, obwohl der Mittelwert womöglich nicht viel mit der tatsächlich genutzten Frequenz zu tun hat, falls der Prozessor im analysierten Zeitraum zwischen langsamen und schnellen Betriebszuständen hin und her gewechselt hat. Die beiden Änderungen, die das alte Verhalten wieder herstellen, wurden auch in 4.13.12 zurückportiert, damit auch diese Kernel-Serie wieder das frühere Verhalten zeigt.

Kompression für Btrfs und Squashfs & Quota-Optimierungen

[55] [56]Neues Kompressionsverfahren für Btrfs und SquashFS

Das Btrfs-Dateisystem und das bei vielen Live-Linuxen verwendete Kompressions- und Image-Dateisystem SquashFS können Daten nun mit Zstandard (kurz: Zstd) komprimieren. Dieser verlustfreie Kompressionsalgorithmus zeichnet sich durch eine Reihe verschiedener Kompressionslevel aus, durch die sich Packdichte sowie der zum Komprimieren benötigte Zeit- und Rechenaufwand flexibel gegeneinander abwägen lassen. Dabei soll Zstd ähnlich schnell komprimieren können wie LZ4, aber [in einer anderen Kompressionsstufe] auch eine an Packqualität erreichen können, die an jene von LZMA heranreicht; beim Dekomprimieren sollen alle drei auf einem ähnlichen Niveau liegen und damit knapp doppelt so schnell sein wie das von gzip verwendete Zlib. Das behauptet zumindest Nick Terrell, der Support für Zstd in den Kernel eingebracht hat und genau wie der Zstd-Entwickler bei Facebook in Lohn und Brot steht.

Terrell hat darüber hinaus auch das Xxhash Modul eingebracht, das Support für die von Zstd verwendeten Hash-Algoithmen xxh32 und xxh64 nachrüstet. Diese sind nicht für kryptografische Zwecke geeignet, sondern nur zur Prüfsummenberechnung – dabei sollen sie aber deutlich schneller arbeiten als Checksumming-Algorithmen wie CRC32.

Hintergründe zum Ganzen erläutern die Zstd-Website [58] und ein Merge-Commit-Kommentar [59]. Etwas mehr in die Tiefe sowie Messergebnisse zu xxh32/xxh64 und zstd finden sich in den Kommentaren der Commits, mit denen Xxhash [60] und Zstd [61] in Linux einflossen; weitere liefern die Änderungen, die Zstd-Support in Btrfs [62] und SquashFS [63] nachgerüstet haben.

[64]Ext4 & Quoten: Dateien schneller erzeugen

Beim Ext4-Dateisystem gab es diesmal nur wenige Änderungen [65]. Eine davon beseitigt ein Skalierungsproblem [66]. Dadurch soll die Menge der maximal pro Sekunde erzeugten Dateien auf Systemen mit vielen CPU-Kernen teilweise drastisch steigen – laut dem zuständigen Entwickler legte das Dateisystem in einem Benchmark sogar um das Zehnfache zu.

Einen Performance-Zuwachs beim Anlegen von Dateien verspricht auch ein Schwung von Änderungen am Quota-Code [67], mit dem sich die Menge der von Anwendern verwendbaren Dateisystem-Ressourcen limitieren lässt. Der zuständige Subsystem-Entwickler erwähnt Berichte, denen zufolge Ext4 in Tests ungefähr um den Faktor 2 zulegte.

Die Eignung für Android-Geräte zu verbessern ist eines der Ziele der Änderungen an F2FS (Flash-Friendly File System) [68]. Das soll beispielsweise durch Patches erreicht werden, die die Performance beim Zusammenspiel mit der Embedded-Datenbank SQLite verbessern sollen (u. a. 1 [69], 2 [70]). Außerdem beherrscht das für Flash-Datenträger optimierte Dateisystem jetzt sowohl Project Quota [71] als auch Journalled Quota [72].

Durch Umbauten an CIFS [73] kann das Dateiystem nun auch erweiterte Attribute (EAs/Xattr) auf Samba- und Windows-Freigaben lesen und schreiben, die SMB2 und neuer verwenden.

Neben den erwähnten Änderungen gab es noch zahlreiche weitere, die die Kommentare der Merge-Window-Commits zu den Dateisystemen Btrfs [74], FUSE [75], GFS2 [76], NFS (1 [77], 2 [78]), NFSd [79], Orangefs [80], Overlayfs/OVL [81], XFS [82]nennen.

[83] [84]Performance-Optimierungen für BFQ

Unter den wesentlichen Änderungen am Block-Layer (1 [86], 2 [87], 3 [88]) sind zahlreiche Optimierungen, die Performance-Probleme des bei Linux 4.12 [89] integrierten Storage-I/O-Schedulers BFQ (Budget Fair Queueing) beheben. Darunter ist beispielsweise eine für Flash-Datenträger relevante Optimierung [90], die bei einem Benchmark auf einem Einplatinencomputer den Durchsatz um 125 Prozent steigern konnte; außerdem haben die Entwickler die Dokumentation zum Feintuning von BFQ [91] verbessert. Ein anderer Satz von Änderungen beseitigt ein Skalierungsproblem [92] in Blq-Mq, durch das ein Aktivieren von Inflight Accounting die Datenträger-Performance erheblich reduzierte.

Allerlei Detailverbesserungen gab es auch bei CEPH [93], Device Mapper [94], Libata [95], Libnvdimm [96], MD [97], MDT [98], MMC [99], Pstore [100], SCSI [101] und der bei Linux 4.13 [102] grundlegend überarbeiteten Writeback-Fehlerhandhabung [103].

Netzwerk-Zerocopy & anfänge eines Kernel-Proxys

[104] [105]Zerocopy Support für sendmsg()

Linux kann dank "Socket Sendmsg MSG_ZEROCOPY" jetzt von Programmen aufbereitete Daten direkt per TCP verschicken, ohne diese zuerst aus dem Speicherbereich einer Anwendung (dem "Userspace") in jenen das Kernels ("Kernelspace") kopieren zu müssen. Das vermeidet Arbeit und soll so die Geschwindigkeit steigern. Der Trick ist keineswegs neu, denn per sendfile() kann Linux schon länger Daten verschicken, ohne diese erst in den Kernelspace kopieren zu müssen. Dieser Ansatz funktioniert aber nur mit Dateien. Der neue setzt hingegen bei sendmsg() an und eignet sich dadurch für Daten, die ein Programm im Speicher hat. Das können einmalig zum Versand aufbereitete Daten sein, wenn beispielsweise ein CMS auf Anfrage eines Nutzers eine individuelle Webseite kompiliert und ausliefert. Bei beiden Ansätzen dupliziert der Kernel die Daten aber sehr wohl, falls die Umgebungsbedingungen das erfordern.

Laut dem zuständigen Entwickler kann der Zerocopy-Ansatz die Prozessorlast in Micro-Benchmarks deutlich verringern. Bei Tests mit weitgehend aus dem Produktionsbetrieb übernommenen Workloads hätte die Technik einen Performance-Vorteil von 5 bis 8 Prozent erzielt. Der Kernel kann das Ganze aber nicht automatisch nutzen: Programme müssen die die Zerocopy-Funktion unterstützen und explizit anfordern, schließlich dürfen sie den Speicherbereich nicht modifizieren, bevor der Kernel die darin enthaltenen Daten auf den Weg geschickt hat.

Weitere Hintergründe zu MSG_ZEROCOPY und dessen Einsatz finden sich in dem Kommentar eines Merge Commit [107], einigen Commit-Kommentaren (1 [108], 2 [109], 3 [110], 4 [111], 5 [112]), der Kernel-Dokumentation [113] und einem Artikel von LWN.net [114]. Noch mehr Details liefern die Videoaufzeichung eines Vortrags [115] des zuständigen Entwicklers sowie die dort gezeigten Präsentationsfolien [116] und ein zugehöriges Paper [117].

[118]XDP-Verbesserungen, Abschied vom IRDA-Netzwerkcode, …

Die Netzwerk-Schnellstraße Express Data Path (XDP) lässt sich dank "XDP Generic" seit Linux 4.12 [119] mit beliebigen Netzwerk-Schnittstellen verwenden. Jetzt beherrscht der dafür verantwortliche Code auch XDP_REDIRECT [120], um Pakete umzuleiten. Die zum Speichern von Geräte-Referenzen gedachte "Devmap" [121] soll dabei helfen, diese Aufgabe möglichst schnell zu erledigen. XDP Generic unterstützt jetzt auch virtuelle Netzwerkgeräte [122]. Darüber hinaus implementiert der Tun-Treiber nun XDP [123], was die Performance bei Tests um mehr als 40 Prozent verbessern konnte.

Die zum SK-Redirect geeignete "Sockmap" [125] und einige andere Umbauten [126] schaffen Grundlagen, auf die ein derzeit in Entwicklung befindlicher "Kernel Proxy" [127] aufbauen soll. Dieser verspricht SSL-Proxies, Application Firewalls und L7 Load Balancer beschleunigen, indem er den Overhead beim Layer-7-Processing reduziert. Ein anderer Kernel-Entwickler hatte zuvor schon einen ähnliche Ansatz für einen Proxy im Kernel umrissen [128].

Linux 4.14 bringt zahlreiche Verbesserungen am Code des BPF – der aus dem klassischen Berkeley Packet Filter (BPF) hervorgegangenen Virtual Machine, mit der XDP, Seccomp, Perf, tcpdump und anderer Kernel- und Userspace-Code den oftmals dynamisch erzeugten Programmcode ausführen, dem diese Techniken oft die Schwerarbeit aufbürden. Zum BPF-Code stieß beispielsweise ein JIT (Just in Time) Compiler für 32-Bit-ARM-Prozessoren [129], der die Ausführungsgeschwindigkeit auf solchen CPUs steigern soll. Die BPF-VM beherrscht neben den Instruktionen BPF_JGT (>), BPF_JGE (>=), BPF_JSGT (s>) und BPF_JSGE (s>=) nun auch die Gegenstücke BPF_JLT (<), BPF_JLE (<=), BPF_JSLT (s<) und BPF_JSLE (s<=) [130]; das soll Overhead vermeiden, der bislang durch Spiegeln der Vergleichsargumente entstand.

Einige weitere Neuerungen rund um Netzwerk-Support des Kernels finden sich im Kommentar eines Merge-Commits [131], mit denen die wesentlichen Änderungen am Netzwerkcode zum Kernel stießen. Mit ihnen haben die Entwickler den IRDA-Code, mit dem sich Netzwerkverbindungen über Infrarot-Sender und -Empfänger aufbauen lassen, in den Staging-Bereich [132] verschoben. Dieser Umzug in den Bereich für Code mit bekannten Qualitätsmängeln läutet den Rauswurf des IRDA-Netzwerk-Supports ein; Anwender, die das verhindern wollen, müssen jetzt an die Kernel-Hacker herantreten. Damit rechnen diese aber nicht, denn bislang habe sich auch niemand beschwert, dass der diese Tage ohnehin eher exotische Kommunikationsweg in aktuellen Linux-Versionen bereits eine Weile nicht mehr richtig funktioniert.

RAM verschlüssen, Kaltstartattacken-Schutz & GCC-Plug-ins

[133] [134]Arbeitsspeicherschutz gegen Kaltstartattacke

Der EFI-Code von Linux unterstützt jetzt eine Technik zum Schutz gegen Angreifer [135], die durch Neustarts an sensible Arbeitsspeicherinhalte zu gelangen versuchen. Bei solch einer Kaltstartattacke (Cold Boot Attack) löst ein Angreifer mit physischem Zugriff auf das System einen sofortigen Reboot aus, um dann mit einem von ihm kontrollierten Betriebssystem alle noch verbliebenen RAM-Inhalte auszulesen. Der jetzt eingeflossene Support für die "TCG Platform Reset Attack Mitigation Specification [136]" erschwert diesen Angriffsweg: Diese Spezifikation implementierende BIOSe löschen beim Neustart alle Speicherinhalte, bevor sie wieder ein Betriebssystem starten. Das kann aber nennenswert Zeit kosten – die Firmware darf sich den Aufwand daher sparen, wenn das Betriebssystem beim Herunterfahren durch Setzen einer Variable anzeigt, dass es keine schützenswerten Speicherinhalte gibt.

[137]Arbeitsspeicher verschlüsseln

Neu ist auch der Support für AMDs "Secure Memory Encryption" (SME), mit der AMDs Epyc-Prozessoren und der für Business-PCs gedachte Ryzen Pro [138] weite Teile des Arbeitsspeichers verschlüsseln können. Anders als der erwähnte Kaltstartattacken-Schutz im EFI-Code hilft das auch gegen Angreifer, die Speichermodule zum Auslesen in ein anderes System verpflanzen. Außerdem schützt SME auch gegen Lauschen (Sniffing) am Speicherbus oder den Diebstahl nichtflüchtiger Speichermodule (NVDIMMs).

AMD zielt mit der Technik aber offenbar vornehmlich auf Cloud-Provider. Dabei ist SME-Support in Linux aber nur der erste von zwei Schritten. Der zweite ist die auf SME aufbauende Secure Encrypted Virtualization (SEV), durch die der Prozessor die von Virtual Machines (VMs) verwendeten Arbeitsspeicherbereiche mit individuellen Keys verschlüsselt. Dadurch können Angreifer die Speicherinhalte anderer VMs nicht einsehen, selbst wenn sie aus einer VM ausbrechen und den Kernel des Hosts unter ihre Kontrolle bringen. Linux 4.14 beherrscht SEV aber nicht, denn die Patches zur Unterstützung in Linux [139] und dessen Hypervisor KVM [140] sind noch in der Begutachtungsphase; sie dürften bald folgen, sofern die Entwickler nicht noch Eigenschaften finden, die gegen eine Integration sprechen.

Weitere Details zu SME und SEV liefert eine im letzten Herbst publizierten Meldung zu AMDs RAM-Verschlüsselung [141]. Weitere Hintergründe zur Memory-Encryption-Technik liefern einige Commit-Kommentare (1 [142], 2 [143], 3 [144], 4 [145], 5 [146], 6 [147], 7 [148], 8 [149], 9 [150], 10 [151], 11 [152], 12 [153], 13 [154]), die zugehörige Dokumentation [155], ein Whitepaper von AMD [156] oder ein älterer LWN.net Artikel [157]. Letzterer erläutert auch die Software Guard Extensions (SGX) von Intel. Diese Speicherverschlüsselung zielt laut dem Online-Magazin eher auf Programme, die sensible Informationen vor lokalen Angreifern schützen wollen, denn mit SGX gehe ein größerer Geschwindigkeitsverlust beim Speicherzugriff einher. Intels Ansatz soll dafür Daten auch ohne VMs vor Angreifern schützen können, die den Kernel unter ihre Kontrolle gebracht haben.

[158]Code beim Kompilieren sichern

Das "Randstruct GCC-Plugin" kann jetzt noch mehr in C programmierten Strukturen (struct) verwürfeln. Das beim Kompilieren des Kernels eingreifende Plug-in erschwert Angreifern ein Auffinden von Pointern in C-Strukturen, die auf häufiger zur Rechteausweitung genutzte Kernel-Funktionen zeigen; das Plug-in unterbindet so ein gezieltes Einspringen über bekannte, bei viele Kernel-Images zu findende Strukturen.

Dieses Plug-in für die GNU Compiler Collection bringt Linux seit Version 4.13 mit. Dort kann es aber nur handverlesene C-Strukturen des Kernel-Codes randomisieren. Durch eine in 4.14 eingeflossene Änderung [159] verwürfelt das Plug-in nun automatisch alle in Frage kommenden C-Strukturen, solange eine Kennzeichnung im Code das nicht explizit untersagt.

Der prinzipbedingte und im Kernel-Log zu Linux 4.13 [160] erwähnte Nachteil des Plug-ins bleibt aber: Für Debian, Fedora, Ubuntu & Co. bringt der Ansatz nur wenig, denn damit Nutzer eigene Module für die Kernel dieser Distributoren erzeugen können, müssten deren Macher den zum Randomisieren verwendeten Zufallswert veröffentlichen – mit dieser Information hätten Angreifer dann aber wieder alles zur Hand, um zur Rechteausweitung dienliche Stellen in C-Strukturen leicht aufzuspüren. Für Hersteller von Embedded-Hardware eignet sich das Ganze daher mehr; ebenso für Facebook, Google und andere Firmen, die in ihren Rechenzentren eigene Kernel einsetzen.

Randstruct war nicht das einzige GCC-Plug-in, an dem die Entwickler geschraubt haben [161]: Das "Structleak Plugin" kann beim Kompilieren jetzt auch Variablen von C-Strukturen initialisieren [162], bei denen struct nicht im Kontext seiner Erzeugung, sondern erst später im Codefluss über Referenzen gefüllt wird. Das Compiler-Plug-in sorgt so bei mehr Code dafür, dass Strukturen nach der Initialisierung keine zuvor im verwendeten Arbeitsspeicherbereich liegende Daten enthalten, sondern Nullwerte. Das in Linux 4.11 [163] integriert Structleak soll so Informationslecks vermeiden, die Angreifern dienlich sein könnten.

[164]Capabilities-Support für Container

In User Namespace laufenden Werkzeuge können nun auch Capabilities [165] setzen, mit denen Programme einige für ihre Arbeit wichtige Rechte nutzen können, die normalerweise dem Root-Anwender vorbehalten sind. Einige Distributionen nutzen Capabilities etwa für ping, damit das Werkzeug automatisch beim Aufruf einige zur Arbeit nötigen Netzwerk-Privilegien erhält, dabei aber nicht mit Root-Rechten läuft, wie es beim SUID-Bit der Fall ist. Die Capabilities sind dabei in erweiterten Attributen (Extended Attributes/EAs) hinterlegt, die sich in einem User Namespace nicht anlegen lassen. Das gelingt jetzt, was etwa zur Installation und zum Bau von RPM-Paketen in Containern wichtig ist, die Capabilities verwenden und die User Namespace nutzen. Bei dieser Namespace-Technik entsprechen die im Container sichtbaren User-IDs nicht jenen des Hosts; vielmehr gibt es ein Mapping, durch das ein Anwender im Container Root (UID=0) sein kann, zugleich auf dem Host aber eine normale, unpriviligierte User-ID hat (UID typischerweise größer 1000). Damit sich ein Root-Anwender im Container über selbst erzeugte Capabilities keine zusätzlichen Rechte verschafft, landen diese in einem anderen erweiterten Attribut als auf dem Host. Details zum Ganzen liefern ein Commit-Kommentar [166]. Auch LWN.net hat einen Artikel zum Capabilities-Support [167] für User Namespaces – die Implementierung hat sich seitdem aber etwas geändert.

[168]Sicherheit allerorten

Wie schon bei den vorangegangenen Linux-Versionen haben Canonical-Mitarbeiter auch bei 4.14 einige Verbesserungen an der Sicherheitslösung AppArmor eingebracht [169]. Darunter sind etwa Mount Mediation [170] sowie Grundlagen zur Signal Mediation [171]; der Basis-Support für Socket Mediation [172] floss auch ein, wurde aber später entfernt [173], weil er bei einigen Anwendern für Probleme sorgte [174]. Einige dieser Funktionen hat das Unternehmen jahrelang nur für den eigenen Ubuntu-Kernel entwickelt. Seit einiger Zeit bemüht sich der Distributor aber endlich um die Integration. Offenbar ist das dem Paketformat Snap zu verdanken, denn dessen Werkzeuge nutzen viele AppArmor-Funktionen zum Abschirmen ("Confinement"), was zu einer der Kernfunktionen von Snap zählt. Auf Distributionen abseits der Ubuntu-Familie gelingt der Sandbox-Betrieb aber bislang oft nicht oder nur eingeschränkt, weil deren Kernel einige der benötigten AppArmor-Funktionen nicht beherrschen. Das bleibt fürs erste aber auch so, denn dem offiziellen Kernel fehlen nach wie vor einige von Snap verwendete AppArmor-Features. Bei Distributionen, die SELinux nutzen, wird die Problematik wohl noch länger bestehen bleiben, denn AppArmor und SELinux können nicht gleichzeitig aktiv sein.

Eine Reihe von Änderungen gab es auch an Treiber und Infrastruktur für Crypto-Beschleuniger [175]. Durch eine davon unterstützt der schon länger in Linux enthaltene Treiber für AMDs Cryptographic Coprocessor (CCP) jetzt auch den "AMD Secure Processor" [176], der in Vega-Grafikchips [177] steckt und einen CCP enthalten soll.

Der ARM- [178], ARM64- [179] und x86-Code [180] enthält jetzt einen Sicherheits-Check, der Adress-Limits bei Zurücksprung in den Userspace prüft, um den Kernel-Code vor dem Überschreiben zu schützen.

Einige unter dem Oberbegriff "Secureexec" entwickelte Änderungen [181] versprechen eine bessere Resourcen-Limitierung per Rlimit bei Programmen, die SETUID oder SETGID nutzen, um mit Rechten anderer Nutzer oder Gruppen zu laufen.

Einige weitere Detailänderungen, die die Sicherheit verbessern, nennen die Merge-Commits der Subsysteme User Namespaces, [182] Seccomp [183] und SELinux [184]. Ferner haben die Entwickler die Implementation von big_key im Key-Subsystem renoviert [185]. Das passiert erst zur dritten Vorabversion von Linux 4.14, nachdem ein Programmierer allerlei Schwachstellen bei der Handhabung großer Schlüssel [186] im Kernel-Keyring bemerkt hatte.

Ressourcenregelung, Speichereinbindung & Feintuning

[187]Ressourcenregelung für Threads

Die zweite Generation der Control Groups bietet mit dem "Cgroup v2 Thread Support [188]" jetzt ein Interface zur Handhabung von Threads. Dieses entstand nach jahrelangen Debatten, die bereits parallel zur Aufnahme der Cgroups v2 in Linux 4.5 [189] aufflammten. Ein Cgroup-v2-Controller zum Regeln der Prozessornutzung war damals schon weit gediehen. Er musste aber draußen bleiben, weil die Entwickler nicht überein kamen, wie Threads von Prozessen gehandhabt werden sollten.

Einige Diskussionsteilnehmer forderten, Prozesse und ihre Threads in unterschiedliche Cgroups stecken zu können. Das war bei den Cgroups v2 aus verschiedenen Gründen nicht vorgesehen – unter anderem, weil es laut dem Cgroup-Maintainer das User-Interface verkompliziert hätte, die Performance verschlechtern würde und bei vielen Controllern gar nicht umsetzbar sei. Nach langem Hin und Her und einigen Experimenten entstand mit dem Thread Support jetzt ein Kompromiss, den LWN.net näher beschreibt [190]. Auf diesen Code soll ein CPU-Controller für Cgroup v2 aufbauen, der bei 4.15 folgen dürfte. Das renovierte Cgroup-Interface dürfte dadurch endlich durchstarten können, denn dann stünden alle wesentlichen Controller auch via Cgroup v2 zur Verfügung.

[191]Externen Speicher leichter einbinden

Nach mehreren Entwicklungsjahren ist eine Infrastruktur zum Heterogeneous Memory Management (HMM) eingeflossen. Sie soll Programmierern eine deutlich simplere und zugleich performantere Nutzung der verschiedenen Arbeitsspeicherbereiche ermöglichen, die sich in modernen Systemen finden. Das ist etwa für Berechnungen mit C++, OpenCL oder CUDA wichtig, denn durch HMM kann der Grafikprozessor leichter Datenstrukturen lesen und schreiben, die im Hauptspeicher liegen. Dadurch müssen Programme beispielsweise die zu verarbeitenden Daten nicht mehr im Arbeitsspeicher verankern (Pinning) oder in den Speicher der Grafikkarte kopieren. Durch HMM können zudem auf dem Hauptprozessor aufgeführte Programme leichter auf den Grafikspeicher zugreifen, um dort ein Ergebnis abzuholen, das die GPU berechnet hat. Das Ganze ist nicht nur für Grafik- beziehungsweise Stream-Processing-Karten interessant, sondern auch für Host Bus Adapter (HBAs), Crypto-Beschleuniger, FPGAs oder DSPs. Details hierzu liefert ein Inhalt und der ausführliche Kommentar eines Commit [192] des zuständigen Entwicklers sowie ein älterer LWN.net-Artikel [193].

[194]Verbesserungen zur Virtualisierung

Zwischen den Patches am Xen-Code [195] war das seit Längerem entwickelte Backend für die "Pvcalls [196]" (u. a. 1 [197], 2 [198]). Bei diesen handelt es sich um einen im Xen-Blog näher beschriebenen Kommunikationsweg [199], der POSIX-Aufrufe von der DomU zur Verarbeitung an die Dom0 leitet. Das soll Overhead bei Virtualisierung mit Xen reduzieren und so die Geschwindigkeit steigern.

Linux bringt jetzt einen "Hyper-V Transport for Virtual Sockets [200]" mit. Dieser bietet einen Kommunikationsweg, über den sich auf einem Windows-Host laufende Anwendungen effizienter und ohne Netzwerkverbindung mit einem Linux austauschen können [201], das unter Microsofts Hypervisor in einer Virtual Machine (VM) läuft.

Unter den wichtigsten Umbauten an KVM (u. a. 1 [202], 2 [203]) waren gleich mehrere, um die Performance von Nested Virtualization zu steigern – also den Betrieb einer VM innerhalb einer anderen VM, die direkt auf dem Host läuft.

[204]Feintuning für mehr Geschwindigkeit

Performance-Verbesserungen sind das Ziel der im Android-Umfeld entstandenen Funktion "Allow remote cpufreq callbacks" (u.a. 1 [205], 2 [206], 3 [207]). Durch sie kann der Prozess-Scheduler einen CPU-Kern gleich zum Hochtakten auffordern, wenn er einen Prozess an diesen delegiert. Bislang konnte der Scheduler das nur beim lokalen CPU-Kern bewirken. Prozesse liefen dadurch beim Start oder Verschieben auf einem anderen Kern zuerst nur langsam, falls sich dieser gerade in einem langsamen und stromsparenden Betriebszustand befand. Ein LWN.net-Artikel [208] erläutert Details.

Vermutlich wird kaum ein Leser hier ein System mit Tausenden von Prozessorkernen sein eigen nennen. Aber falls doch: Unter den Änderungen am Scheduler waren einige [209], die den Start des Kernels auf solchen Systemen deutlich beschleunigen [210] sollen.

Beim Memory-Management-Code gab es zahlreiche Detailverbesserungen, von denen einige die Performance unter bestimmten Umgebungsbedingungen steigern – teilweise sogar deutlich. Details hierzu finden sich in Commit-Kommentaren zu Features wie "add /proc/pid/smaps_rollup [212]", "page_alloc: rip out ZONELIST_ORDER_ZONE [213]", "add swap readahead hit statistics [214]", "add sysfs interface for VMA based swap readahead [215]", "VMA based swap readahead [216]", "Choose swap device according to numa node [217]", "delay splitting THP after swapped out" [218] oder dem auch bei LWN.net [219] erläuterten "membarrier: Provide expedited private command [220]". Einen Performance-Gewinn verspricht auch eine neue Cache-Funktion im Red-Black-Tree-Code [221] des Kernels.

Beim Subsystem für Dokumentation gab es weniger Änderungen als zuletzt [222]. Zufällig hat eine Reihe von Entwicklern aber einige wichtige Dokumente grundlegend überarbeitet und auf einen aktuellen Stand gehievt, darunter etwa die Beschreibungen zu den unterstützten Schlafzuständen [223], dem Microcode-Loader [224], der SMB3-Unterstützung [225], dem bei 4.13 eingefügten Writeback-Fehlerdatentyp errseq_t [226] sowie den Locking-Mechanismen atomic_t [227], RCU (Read-Copy-Update) [228] und Rtmutex [229].

Durch die neue "Crossrelease"-Funktion [230] kann Lockdep jetzt in noch mehr Situationen automatisch prüfen [231], ob Kernel-Code die gesetzten Locks korrekt sperrt und entsperrt.

Bei der Kernel-Infrastruktur und den Werkzeugen für Performance-Monitoring und -Analysen mit Perf gab es wieder zahlreiche wichtige Verbesserungen, die ein Commit-Kommentar erläutert [232]. Darunter sind neben Namespace-Support beispielsweise auch Branch-Type Profiling/Tracing Support (u. a. 1 [233], 2 [234], 3 [235], 4 [236]). Durch einige Erweiterungen können Tools wie perf mem jetzt auch physische Speicheradressen ausgeben (u. a. 1 [237], 2 [238], 3 [239], 4 [240], 5 [241]). Außerdem kann perf annotate jetzt mit einem Symbol direkt anzeigen [242], wenn der Codefluss durch eine Macro-Operation Fusion [243] optimiert wurde.

Details zu anderen Neuerungen im Bereich Infrastruktur finden sich in den wichtigsten Commits der Subsysteme ACPI [244], Cgroups [245], Device Tree (DT) [246], Device Properties Framework [247], EFI [248], IOMMU [249], Kbuild [250], Kselftests [251], Locking [252], PCI [253], Percpu [254], Power Management [255], Thermal [256], RCU [257] und VFIO [258]. Das sind übrigens nur jene Merges dieses Bereichs, die der Autor aus dem ein oder anderen Grund für erwähnenswert hielt; einige Dutzende andere haben diese Hürde nicht geschafft. Das gleiche gilt auch für andere Aufzählungen dieser Art, die dieser Text enthält.

[259]Feintuning am Architekturcode

Einen kleinen Performance-Gewinn verspricht die Unterstützung für Process Context ID (PCID) im x86-Code. Durch diese in neueren Intel-Prozessoren zu findende Technik kann der Kernel häufig vermeiden, die im TLB (Translation Lookaside Buffer) zu Caching-Zwecken gespeicherten Daten zu verwerfen, wenn der Kernel von einem Prozesskontext zu einem anderen wechselt. Bei anderen Architekturen heißt das "Address space ID". Die Entwickler nennen die Unterstützung für Intels Implementation allerdings "unorthodox" [261]: Die Hardware hat einige Beschränkungen; daher müssen die Entwickler zu Tricks greifen, damit PCID tatsächlich die Geschwindigkeit steigert. Falls PCID Probleme bereitet, kann man es über die neue Boot-Option nopcid deaktivieren [262].

Vollkommen unabhängig davon gab es im x86-Code noch einige Optimierungen an der Hyper-V-Unterstützung [263]. Diese versprechen nicht nur, Hypercalls zu Microsofts Hypervisor zu beschleunigen (u. a. 1 [264], 2 [265]), sondern auch das Leeren des TLB in darunter laufenden Virtual Machines (VMs) schneller und besser zu machen (u. a. 1 [266], 2 [267]).

Der Kernel enthält jetzt Device-Tree-Bindings und eine Konfiguration für den Raspberry Pi Zero W (u. a. 1 [268], 2 [269], 3 [270]). Neu dabei ist auch Support für die Single-Board-Computer Banana Pi R2 (BPI-R2) [271] und Banana Pi M3, M2M and M64 [272].

Weitere Details zu Änderungen am Architektur-Code nennen die Merge Commits zu den Subsystemen ARC [273], ARM (Core [274], Drivers [275], Device Tree [276], Platforms [277]), ARM64 [278], MIPS [279], Parisc [280], PowerPC [281], S390 (1 [282], 2 [283]), SPARC [284] und x86 (ASM [285], Cache Quality Monitoring [286], FPU [287], Memory Management [288]).

Optimierte Grafiktreiber & neue DVB- und LAN-Treiber

Zahlreiche neue und verbesserte Treiber

Linux-Kernel 4.14 enthält überarbeitete Grafiktreiber, die Hardware-Support und Performance verbessern. Neu dabei ist auch ein Treiber für ein Display eines Lego-Mindstorm-Roboters. Auch die Unterstützung für DVB-S2-Hardware haben die Kernel-Entwickler verbessert. Außerdem bringt Linux jetzt einen Treiber für einen neuen WLAN-Chip von Realtek mit.

[289] [290]Silberstreifen am Horizont bei Amdgpu

Der für moderne Radeon-GPUs zuständige Amdgpu-Treiber kann jetzt große Speicherseiten (Huge Pages) nutzen [291], die Overhead beim Speicherzugriff vermeiden und so die Performance steigern – insbesondere beim Rechnen mit GPUs (General-purpose computing on Graphics Processing Units). Ferner gab es allerlei Verbesserungen und Feintuning rund um den Support von Vega-Grafikkarten, der GPU-Virtualisierung mit SR-IOV und dem Support der Stromspartechnik PowerPlay. Zudem haben AMDs Entwickler eine Reihe von Patches integriert [292], durch die AMDs als "Platform for GPU-Enabled HPC and Ultrascale Computing" umschriebenes GPGPU-Framework ROCm [293] jetzt mit dem offiziellen Kernel funktioniert; bislang klappt das allerdings nur mit den APUs [294] der Prozessorgenerationen Kaveri und Carrizo.

Mit Vega-Grafikkarten und den GPUs in AMDs jüngst vorgestelltem Ryzen Mobile [295] kann der Treiber aber nach wie vor keine Bildschirme ansteuern, denn dazu ist weiterhin die anfangs als DAL (Display Abstraction Layer) und mittlerweile als DC (Display Core) bekannte Patch-Sammlung erforderlich. Dieses Manko löst sich aber womöglich bald in Luft auf, denn der für die Grafiktreiber zuständige Entwickler Dave Airlie scheint Linus Torvalds bitten zu wollen, DC in Linux 4.15 zu integrieren. Airlie und einige andere Kern-Entwickler des für Grafiktreiber zuständigen Kernel-Subsystems hatten diese von AMD selbst entwickelte Patch-Sammlung anfangs rundweg abgelehnt, weil sie ihren Qualitätsansprüchen nicht genügte. Hauptgrund, vereinfacht gesagt: Die Patches sorgten für eine Abstraktionsschicht zwischen Treibercode und dem Atomic-Framework der Kernels, die als Basis für modernen Kernel-Grafiktreiber gedacht ist. Erschwerend kam hinzu, dass DAL einige Funktionen reimplementierte, die Atomic bereits bot. Airlie & Co. sahen daher viele Code des Ganzen als Ballast an, der Pflege und Weiterentwicklung unnötig verkompliziert hätte.

Nach allerlei Diskussionen haben die AMD-Entwickler das eingesehen und begonnen, den Treiber anzupassen, damit er die Ansprüche von Airlie & Co erfüllt. Nach tiefgreifenden Umbauten und rund 20 Monaten Entwicklungszeit baten sie dann kürzlich um die Aufnahme von DC [296]. Airlie fand dann noch einige Probleme, die AMDs Entwickler oder er selbst ausräumten. Offenbar ist Airlie jetzt zufrieden und will den Code zur Aufnahme einsenden; Torvalds könnte sich aber an Eigenschaften stören und so die Aufnahme vertragen, bis seine Kritik behoben wurde. Das Risiko gibt es immer – bei DC ist es aber größer, weil es aus über 800 Patches besteht, die viel neuen Code mitbringen.

[297]Intel verbessert Vulkan-Support

Der für die modernen Intel-GPUs zuständige Treiber i915 beherrscht jetzt Render Decompression Support; dadurch kann der Treiber bestimmte Daten jetzt komprimiert im Grafikspeicher ablegen, was Speicherbandbreite spart und so die Performance verbessert. Außerdem beherrscht der Treiber nun DRM Syncobjs [298]; mit ihrer Hilfe soll der in Mesa enthaltene Vulkan-3D-Treiber den bei Vulkan 1.0.42 hinzugekommenen Befehl VK_KHX_external_semaphore unterstützen, der eine Synchronisation von Speicherzugriffen ermöglicht.

Unter einer Reihe weiterer Änderungen waren mehrere, um den Support für die seit Linux 4.8 [299] mögliche GPU-Virtualisierung mit Intels Graphics Virtualization Technology (GVT) robuster und schneller zu machen. Intels Entwickler haben zudem die Unterstützung für die GPU der Cannon-Lake-Prozessoren verbessert, die in den nächsten Monaten auf den Markt kommen sollen. Der Support für die bereits erhältlichen und zur Core-i-8000-Serie gehörenden Coffee-Lake-Prozessoren wird indes weiterhin nur aktiv, wenn man den Parameter i915.alpha_support=1 spezifiziert; ab 4.15 soll das nicht mehr nötig sein [300].

[301]Unterstützung für neue GeForce-Karte

Der Nouveau-Treiber des Kernel unterstützt jetzt auch die GeForce GT 1030, denn es weiß jetzt auch dessen NV138 oder GP108 genannten Grafikchip anzusprechen [302]. 3D-Beschleunigung gelingt bislang nicht, denn Nvidia hat bislang keine für diesen Chip geeignete Firmware veröffentlicht, die in die Firmware-Sammlung linux-firmware [303] einfließen könnte.

[304]Grafiktreiber für Raspberry Pi, Lego Mindstorm EV3, …

Der für die Grafikkerne der verschiedenen Raspberry-Pi-Modelle zuständige Treiber VC4 unterstützt jetzt HDMI CEC (Consumer Electronics Control) [305]. Dabei handelt es sich um einen Standard [306], um mehrere per HDMI verbundene Geräte über eine Fernbedienung zu steuern.

Neben den erwähnten Neuerungen bei Grafiktreibern gab es noch Hunderte weitere. Einige der wichtigsten nennt ein Kommentar des Git-Commits [307], der die wesentlichen Änderungen am Direct Rendering Manager (DRM) und seinen Treibern gebracht hat. Darunter ist ein Grafiktreiber für den STM32 DSI Controller [308].

Ebenfalls neu: Ein Treiber für den LCD-Controller Sitronix ST7586, den das Panel des Lego-Roboters Mindstorm EV3 [309] nutzt. Der Code baut auf dem bei Linux 4.11 [310] integrierten Tinydrm auf, mit dem sich recht einfach Treiber für simple und oft via I2C oder SPI angeschlossene Bildschirm-Panel schreiben lassen.

Darüber hinaus gab es einige Detailänderungen am Framebuffer-Subsystem [311], das früher die von Embedded-Grafiktreibern bevorzugte Basis war.

[312]Noch mehr neue und verbesserte Treiber

Die Kernel-Entwickler haben auch zahlreiche andere Treiber überarbeitet und neue integriert, um die Hardware-Unterstützung zu verbessern. Die Alsa- und ASoC-Treiber unterstützten jetzt etwa die Audio-Funktion von Cannon-Lake-Prozessoren, die Intel offenbar in den nächsten Monaten einführen will (1 [313], 2 [314], 3 [315], 4 [316], 5 [317]). Die Änderungen am Media-Subsystem haben gleich einen ganzen Schwung neuer Treiber [318] gebracht, die etwa Support für den ST STV0910 DVB-S/S2 Demodulator [319], den ST STV6111 DVB-S/S2 Tuner [320] oder den Tuner-Demodulator MaxLinear MxL5xx DVB-S/S2 bringen [321]. Zudem gab es größere Umbauten an ddbridge, durch die der Treiber jetzt auf den MXL5xx-Chips aufbauenden DVB-S-Hardware Digital Devices Max S4/8 und Octopus Max unterstützt [322].; außerdem weiß der Treiber jetzt auch CineS2 V7(A) und DuoFlex S2 V4 [323] anzusprechen.

Der Netzwerktreiber e1000e hat bereits jetzt gelernt, zwei neue Generationen des als "LAN on Motherboard" (LOM) eingestuften Netzwerk-Chips Intel i219 [324] anzusprechen. Diese sollen ein Teil der 2018 oder 2019 erwarteten Ice-Lake-Plattform sein, zu der vermutlich auch Core-i-Prozessoren der 9000er-Serie gehören. Solch vorausschauend in Linux einfließender Treiber-Support macht es Anwendern leicht, denn dadurch werden bereits die im Frühjahr erscheinenden Distributionen die neuen Intel-Chips unterstützen, die womöglich einige Monate später auf den Markt kommen.

Im Bereich für Code mit größeren Qualitätsmängeln findet sich jetzt ein Treiber für den 802.11ac-WLAN-Chip RTL8822BE von Realtek [325]. Durch solch neue oder verbesserte Treiber unterstützt Linux 4.14 knapp vierhundert Geräte oder Geräteklassen mehr als sein Vorgänger; bei rund 30 davon handelt es sich um PCI/PCIe- oder USB-Geräte, wie die Datenbanken der Linux Kernel Driver DataBase (LKDDb) [326] zeigen. Darüber hinaus gab es wieder viele Detailverbesserungen, die oft nur wenige Geräte betreffen. Einige Beispiele für Notebooks und Convertibles von Asus: Die Entwickler haben für Unterstützung der Multimedia-Keys des Asus Transformer Pro T304UA [327] und des Touchpads vom Asus Transformer Book T100 [328] gesorgt. Beim Asus ROG G752xx und einigen anderen Notebooks funktioniert das Touchpad besser; das ist Änderungen am Elantech-Treiber zu verdanken [329], durch die er jetzt Touchpads mit zwei Maustasten von Clickpads unterscheiden kann, bei der allein die Fingerposition über Links- oder Rechtsklick entscheidet.

Details zu diesen und weiteren Neuerungen rund um Treiber finden sich in den Kommentaren der Commits, die das Gros der Änderungen der folgenden Subsysteme gebracht haben: Character Devices [330], Driver Core [331], Input (1 [332], 2 [333]), Human Interface Devices (HID) [334], Hardware-Monitoring [335], Platform Drivers x86 [336], RDMA [337], Sound [338], Staging [339], TTY [340], USB [341] und Watchdog [342].

Darüber hinaus haben die Entwickler die ganzen Firmware-Dateien entfernt [343], ohne die eine Reihe von Treibern nicht funktioniert. Diese Dateien lagen bislang in den Linux-Quellen unterhalb von firmware/. Dort wurden sie aber schon länger nicht mehr aktualisiert, um Anwender zum Umstieg auf die unabhängig vom Kernel gepflegte Firmware-Sammlung linux-firmware [344] zu bewegen. Alle Mainstream-Distributionen sind bereits seit einer Weile auf diese umgestiegen.

Lizenz-Statement gegen Trolle & SPDX-Kennzeichnungen

[345]Lizenz-Klarstellung gegen "Copyright-Trolle"

In den Linux-Quellen findet sich jetzt ein "Linux Kernel Enforcement Statement [346]" genanntes Dokument. Mit ihm versucht eine Reihe von Linux-Entwicklern klarzustellen, wie sich ein Verstoß gegen die Lizenz des Linux-Kernels auf das Vertriebsrecht auswirkt. Was zunächst vielleicht nach langweiligem Juristen-Zeug klingt, hat größere Bedeutung – insbesondere für Firmen, Institutionen oder Personen in Deutschland, die GPL-lizensierte Software vertreiben. In die letzte Gruppe gehört auch der Linux-Kernel, der unter Version 2 der verbreiteten Open-Source-Lizenz steht.

Mit dem Dokument versuchen die Kernel-Entwickler, Bestrebungen von gemeinhin als "Copyright-Trollen" bezeichneten Firmen oder Individuen zu unterminieren. Diese versuchen sich zu bereichern, indem sie Verletzungen der GPL vor den Kadi bringen. Das Ganze ist vor allem eine Reaktion auf Aktivitäten des früheren Kernel-Entwicklers Patrick McHardy. Der soll seit mindestens vier Jahren über 50 Lizenzverletzungen angemahnt und zum Teil vor Gericht gebracht haben, was Zahlungen von mehreren Millionen Euro nach sich gezogen haben soll. Das geht unter anderem aus Recherchen von opensource.com [347] respektive Greg Kroah-Hartman [348] hervor, laut denen diese Rechtsstreitigkeiten vornehmlich in Deutschland stattfinden.

Unterlassungserklärung als Hebel für Vertragsstrafen

Laut Informationen, die öffentlich oder hinter vorgehaltener Hand kursieren, bereichern sich Copyright-Trolle unter anderem mit Vertragsstrafen. Sie weisen beispielsweise Firmen oder Institutionen auf eine Lizenz-Verletzung hin, um parallel zur Beseitigung des Problems zum Unterzeichnen einer Unterlassungserklärung zu drängen. Später unterstellt der Troll dann eine weitere Copyright-Verletzung und macht die in der Unterlassungserklärung vereinbarte Vertragsstrafe geltend.

Gegen derlei Vorgehen sollen zwei im Enforcement Statement des Linux-Kernels enthaltene Passagen helfen, die aus der GPLv3 übernommen wurden. Diese stellen klar, dass Unternehmen den Linux-Kernel nach Beseitigung der Lizenzverpflichtung erneut vertreiben dürfen. Außerdem geben sie den Unternehmen ein Zeitfenster von 30 Tagen, um die Verletzung aus der Welt zu schaffen. Laut einer gängigen Interpretation erlischt das Vertriebsrecht von GPLv2-lizenzierter Software bei einem Lizenzverstoß sofort; Copyright-Trolle nutzen das offenbar als Hebel, um Unternehmen unter Druck zu setzen.

Die beiden Passagen sind allerdings keine Ergänzung der Lizenz des Kernels. Sie sind vielmehr eine Absichtserklärung jener Linux-Programmierer, die das Dokument für sich oder für ihr Unternehmen unterzeichnet haben. Beim Entstehen dieser Textzeilen hatten 105 Entwickler das Dokument signiert, darunter viele bekannten Größen wie Linus Torvalds, Greg Kroah-Hartman, David S. Miller oder Ingo Molnar. Die Autoren des Dokuments hoffen anscheinend, dass sich die Erklärung auf Gerichtsverfahren auswirkt. Eine offizielle Lizenz-Ergänzung wäre dabei natürlich ein besserer Hebel. Eine solche wäre aber schon allein durch die vielen Copyright-Halter wohl nur schwer umsetzbar, selbst wenn McHardy nicht einer von ihnen wäre.

Hintergründe

McHardy ist keineswegs ein kleines Licht unter den Kernel-Programmierern; er war einer der Hauptentwickler hinter dem für Firewalls zentralen Netfilter-Code und wird daher sogar in der Credits-Datei genannt [349], die einige der wichtigsten Linux-Entwickler und ihre Beiträge nennt. Das Netfilter-Core-Team hat McHardy aufgrund seiner Aktivitäten im Sommer 2016 suspendiert [350] und zugleich ein Statement veröffentlicht [351], wie ihrer Ansicht nach mit Lizenzverletzungen umzugehen sei. Die Entwickler haben der Problematik zudem einen längeren Abschnitt in ihrer FAQ [352] gewidmet. Dieser rät Firmen unter anderem, Lizenzverletzungsanschuldigungen von McHardy nicht als informelle Verhandlung zu betrachten, weil solche letztlich mehrfach vor Gericht gelandet seien.

Die vorangegangenen Absätze beschreiben die wichtigsten Eckdaten der seit einer Weile köchelnden Lizenz-Troll-Problematik lediglich im Groben; eine detaillierte Beschreibung würde den Rahmen des Kernel-Logs sprengen – unter anderem auch, weil Lizenztexte ab einem gewissen Punkt schlicht Auslegungssache von Juristen und Gerichten werden. Hintergründe zum Vorgehen McHardys erläutert ein im August bei opensource.com erschienener Artikel [353]. Die im Juli 2016 respektive Mai 2017 erschienenen LWN.net-Artikel "On the boundaries of GPL enforcement [354]" und "The rise of copyright trolls [355]" liefern weitere Details zur Problematik.

Was sich die unterzeichnenden Kernel-Entwickler vom Linux Kernel Enforcement Statement erhoffen, umreißt Greg Kroah-Hartman in einem Blog-Beitrag [356] und einer begleitenden FAQ [357]. Diese hat er Mitte Oktober freigegeben – letztlich also kurz bevor das Statement in den Hauptentwicklungszweig von Linux einfloss [358], aus dem Linux 4.14 hervorgeht.

[359]Lizenz-Auszeichnung im Quellcode

Apropos Lizenzen: Rund ein Fünftel der in den Linux-4.14-Quellen steckenden Dateien enthält jetzt einen SPDX-License-Identifier, der die Lizenz der jeweiligen Datei im Kopfbereich in einem Einzeiler explizit ausweist. Compliance-Analyse-Werkzeuge für das Software Package Data Exchange (SPDX) [360] genannte Format können dadurch die Lizenz der verwendeten Dateien eindeutig bestimmen. Das ist vor allem für Firmen interessant, die beim Kombinieren unterschiedlich lizenzierter Open-Source-Software sicher gehen wollen, nicht gegen Verpflichtungen einer der involvierten Lizenzen zu verstoßen.

Die Kernel-Entwickler haben die SPDX-Auszeichnung jetzt bei Dateien hinzugefügt [361], die im Kopfbereich bislang keine Lizenz ausweisen. Diese stehen automatisch unter der GPLv2, der Linux unterliegt. Einige Dateien von Linux stehen allerdings auch unter der MIT- oder BSD-Lizenz, denn darunter liegender Code kann in GPLv2-Projekte einfließen, weil die Lizenzen in der Richtung als kompatibel gelten [362].

Beim den in include/uapi/ liegenden Header-Dateien, die das Userspace-API definieren, lautet die SPDX-Kennzeichnung "GPL-2.0+ WITH Linux-syscall-note". Diese Auszeichnung weist damit explizit auf die ganz oben in der Copyright-Datei von Linux stehende Klarstellung [363] hin, dass die Lizenz nicht auf Userspace-Programme übergreift, die Linux-Kernel-Funktionen über Syscalls ansprechen.

Ausblick auf 4.15, Umfang der Änderungen & Changelog

[364]Entwicklung von Linux 4.15 beginnt

Mit der Freigabe von Linux 4.14 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 integriert er daher viele tausend Änderungen, die in den letzten Wochen zur Aufnahme für 4.15 vorbereitet wurden. Darunter ist neben den erwähnten DC-Patches von AMD eine neue "Closed hash table", die in bestimmten Situationen die Performance verbessern soll. Ferner soll Basis-Support für die offene und freie RISC-V Instruction Set Architecture (ISA) [366] zum Kernel stoßen, die ein seit kurzem erhältlicher IP-Core [367] von SiFive implementiert.

Linux 4.15 soll zudem ein neues Schutzverfahren erhalten, um Überläufe von Referenzzählern zu erkennen. Der Code für diese "Fast Refcount Overflow Protection" steckt sogar schon in 4.14 – die Entwickler haben ihn aber lahmgelegt, um mehr Zeit zum Beseitigen eines plötzlich aufgetretenen Problems zu haben. Außerdem sind Verbesserungen am BPF-Interpreter und der Infrastuktur zum Kernel Live Patching (KLP) geplant. Beim XFS-Dateisystem ist eine Fortsetzung der bei Linux 4.8 [368] begonnen Erweiterungen geplant, die Funktionsumfang und Arbeitsweise des Dateisystems ein weiteres Mal stark verändern.

Linus Torvalds beendet das Merge Window typischerweise nach zwei Wochen, wenn er die erste Vorabversion einer neuen Kernel-Version veröffentlicht. Das läutet zugleich die Stabilisierungsphase ein, die derzeit meist sieben oder acht Wochen dauert. Linux 4.15 erscheint daher wahrscheinlich Mitte Januar.

[369]Daten und Zahlen zu den jüngsten Versionen des Linux-Kernels

[379]

(thl [380])

URL dieses Artikels:
https://www.heise.de/-3831941

Links in diesem Artikel:
[1] http://kroah.com/log/blog/2017/09/06/4-dot-14-equals-equals-this-years-lts-kernel/
[2] https://www.kernel.org/category/releases.html
[3] #orc
[4] #s2i
[5] #la57
[6] #sme
[7] #zerocopy
[8] #hmm
[9] #zstd
[10] https://www.heise.de/news/Linux-5-6-freigegeben-Wireguard-und-USB4-Support-4655269.html
[11] https://www.heise.de/news/Highlights-von-Linux-5-5-Wireguard-Fundament-und-Performance-Verbesserungen-4605827.html
[12] https://www.heise.de/news/Highlights-von-Linux-5-4-exFAT-I-O-Controller-und-Treiber-fuer-neue-AMD-GPUs-4541639.html
[13] https://www.heise.de/news/Linux-5-3-bringt-Treiber-fuer-AMDs-neue-Grafikchip-Generation-4470638.html
[14] https://www.heise.de/news/Linux-5-2-festgeklopft-Neue-ARM-Treiber-und-Case-Insensitivity-fuer-Ext4-Dateisystem-4424484.html
[15] https://www.heise.de/news/Linux-5-1-Performance-Verbesserungen-und-neue-Speichertechnik-4411986.html
[16] https://www.heise.de/news/Linux-5-0-ist-da-Geschwindigkeit-zurueckerobern-und-moderner-speichern-4307315.html
[17] https://www.heise.de/hintergrund/Linux-4-20-freigegeben-Performance-Optimierungen-und-neue-Treiber-4223066.html
[18] #fsmisc
[19] #coldboot
[20] #gccplugins
[21] #gpu
[22] #driversmisc
[23] #spdx
[24] #enforcement
[25] #outlook
[26] 
[27] https://git.kernel.org/torvalds/c/b0c79f49c343cda8954b3322984c32f258ca4ccb
[28] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/Kconfig.debug?id=v4.14-rc1#n367
[29] http://www.codeblueprint.co.uk/2017/07/31/the-orc-unwinder.html
[30] https://lwn.net/Articles/728339/
[31] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/x86/orc-unwinder.txt
[32] https://git.kernel.org/torvalds/c/ee9f8fce99640811b2b8e79d0d1dbe8bab69ba67
[33] https://git.kernel.org/torvalds/c/627fce14809ba5610b0cb476cd0186d3fcedecfc
[34] https://git.kernel.org/torvalds/c/a34a766ff96d9e88572e35a45066279e40a85d84
[35] https://git.kernel.org/torvalds/c/81d387190039c14edac8de2b3ec789beb899afd9
[36] https://git.kernel.org/torvalds/c/39358a033b2e4432052265c1fa0f36f572d8cfb5
[37] 
[38] 
[39] https://git.kernel.org/torvalds/c/b1b6f83ac938d176742c85757960dec2cf10e468
[40] https://git.kernel.org/torvalds/c/77ef56e4f0fbb350d93289aa025c7d605af012d4
[41] https://lwn.net/Articles/717293/
[42] https://git.kernel.org/torvalds/c/855feb6736403f398dd43764254c5f0522bfc130
[43] https://git.kernel.org/torvalds/c/fd8cb433734eeb870156a67f5d56b6564cd2ea94
[44] 
[45] 
[46] https://www.heise.de/ct/ausgabe/2016-25-XPS-13-Developer-Edition-9360-Neuauflage-des-Linux-Ultrabooks-von-Dell-3493490.html
[47] https://git.kernel.org/torvalds/c/71630b7a832f699d6a6764ae75797e4e743ae348
[48] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3596869.html
[49] https://git.kernel.org/torvalds/c/e870c6c87cf9484090d28f2a68aa29e008960c93
[50] #changelog
[51] 
[52] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3771362.html
[53] https://git.kernel.org/torvalds/c/890da9cf098364b11a7f7f5c22fa652531624d03
[54] https://git.kernel.org/torvalds/c/941f5f0f6ef5338814145cf2b813cf1f98873e2f
[55] 
[56] 
[57] https://github.com/facebook/zstd
[58] http://www.zstd.net
[59] https://git.kernel.org/torvalds/c/e7cdb60fd28b252f1c15a0e50f79a01906124915
[60] https://git.kernel.org/torvalds/c/5d2405227a9eaea48e8cc95756a06d407b11f141
[61] https://git.kernel.org/torvalds/c/73f3d1b48f5069d46ba48aa28c2898dc93185560
[62] https://git.kernel.org/torvalds/c/5c1aab1dd5445ed8bdcdbb575abc1b0d7ee5b2e7
[63] https://git.kernel.org/torvalds/c/87bf54bb43ddd385d2538b777324bf737f243042
[64] 
[65] https://git.kernel.org/torvalds/c/be6297e9be118d89fa477a60ddfbf0e0b2dfacec
[66] https://git.kernel.org/torvalds/c/901ed070df3c2c19e3083a734eafc82599fe991b
[67] https://git.kernel.org/torvalds/c/ae8ac6b7dbfd67f883050421fd195c153d02f5f3
[68] https://git.kernel.org/torvalds/c/6d8ef53e8b2fed8b0f91df0c6da7cc92747d934a
[69] https://git.kernel.org/torvalds/c/e65ef20781cbfcbfe2d62ce37e028964bc34b313
[70] https://git.kernel.org/torvalds/c/774e1b78a0f90a7e81f7a23d9ebfa8b8233c1ffa
[71] https://git.kernel.org/torvalds/c/5c57132eaf5265937e46340bfbfb97ffb078c423
[72] https://git.kernel.org/torvalds/c/4b2414d04e99120ce852ba15a1926c9c3a77d9ce
[73] https://git.kernel.org/torvalds/c/8dc5b3a6cb2fc5d4f751bda56a378589202a118b
[74] https://git.kernel.org/torvalds/c/66ba772ee3119849fcdd8ac9766c6c25ede4a982
[75] https://git.kernel.org/torvalds/c/e7989f973ae1b90ec7c0b671c81f7f553affccbe
[76] https://git.kernel.org/torvalds/c/77d0ab600af4bf5152bc98d0ac1edbc34c1e5fdf
[77] https://git.kernel.org/torvalds/c/8e7757d83d07cc77ee2661e9615a2f9f4ce540cd
[78] https://git.kernel.org/torvalds/c/6ed0529fef09f50ef41d396cb55c5519e4936b16
[79] https://git.kernel.org/torvalds/c/ad9a19d003703ae06a6e8efc64cf26a939d9e84d
[80] https://git.kernel.org/torvalds/c/30db202e54d251e4887935f7b4538b44911bb091
[81] https://git.kernel.org/torvalds/c/c353f88f3de485a059e5c003721e2dc276d02fad
[82] https://git.kernel.org/torvalds/c/5791577963426c5a2db51fff57e9fcd72061e2c3
[83] 
[84] 
[85] https://git.kernel.org/torvalds/c/edaf94285bf98375d45cc95bbfd4b9d57796c864
[86] https://git.kernel.org/torvalds/c/a0725ab0c7536076d5477264420ef420ebb64501
[87] https://git.kernel.org/torvalds/c/126e76ffbf78d9e948b641aadb265d16c57f5a3d
[88] https://git.kernel.org/torvalds/c/80a0d644d37296d7cac1a4956cb4e916770083e0
[89] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3712705.html
[90] https://git.kernel.org/torvalds/c/edaf94285bf98375d45cc95bbfd4b9d57796c864
[91] https://git.kernel.org/torvalds/c/2670cd1674055ab48a9607472c5ff14781b9b2ea
[92] https://www.spinics.net/lists/linux-block/msg15631.html
[93] https://git.kernel.org/torvalds/c/cdb897e3279ad1677138d6bdf1cfaf1393718a08
[94] https://git.kernel.org/torvalds/c/dff4d1f6fe85627b7ce8e4c5291d8621a1995605
[95] https://git.kernel.org/torvalds/c/3b9f8ed25dbe5f858b1331588929f2a766aef55f
[96] https://git.kernel.org/torvalds/c/89fd915c402113528750353ad6de9ea68a787e5c
[97] https://git.kernel.org/torvalds/c/3645e6d0dc80be4376f87acc9ee527768387c909
[98] https://git.kernel.org/torvalds/c/a59e57da49f7c3f3de8cf4b7568a0c6c82f5b242
[99] https://git.kernel.org/torvalds/c/15d8ffc96464f6571ecf22043c45fad659f11bdd
[100] https://git.kernel.org/torvalds/c/21d236bf2bde518844b5675ec4980f4b2fd13e1a
[101] https://git.kernel.org/torvalds/c/572c01ba19ef150e98aea0b45ca17d43356521b5
[102] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3771362.html
[103] https://git.kernel.org/torvalds/c/ec3604c7a5aae8953545b0d05495357009a960e5
[104] 
[105] 
[106] https://git.kernel.org/torvalds/c/35615994c1f712946eb4c3d656a695336621e3df
[107] https://git.kernel.org/torvalds/c/35615994c1f712946eb4c3d656a695336621e3df
[108] https://git.kernel.org/torvalds/c/1f8b977ab32dc5d148f103326e80d9097f1cefb5
[109] https://git.kernel.org/torvalds/c/76851d1212c11365362525e1e2c0a18c97478e6b
[110] https://git.kernel.org/torvalds/c/52267790ef52d7513879238ca9fac22c1733e0e3
[111] https://git.kernel.org/torvalds/c/4ab6c99d99bb1bf0fbba8ff4e52114c66109992f
[112] https://git.kernel.org/torvalds/c/f214f915e7db99091f1312c48b30928c1e0c90b7
[113] https://git.kernel.org/torvalds/c/cc8889ae8298ebfc6bbf52ad98fe3b5afdf4ae70
[114] https://lwn.net/Articles/726917/
[115] https://www.youtube.com/watch?v=9F8I9vYQydU
[116] https://netdevconf.org/2.1/slides/apr6/msgzerocopy-willemdebruijn-20170405.pdf
[117] https://netdevconf.org/2.1/papers/netdev.pdf
[118] 
[119] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3712705.html
[120] https://git.kernel.org/torvalds/c/6103aa96ec077c976e851e0b89cc2446cb76573d
[121] https://git.kernel.org/torvalds/c/546ac1ffb70d25b56c1126940e5ec639c4dd7413
[122] https://git.kernel.org/torvalds/c/d445516966dcb2924741b13b27738b54df2af01a
[123] https://git.kernel.org/torvalds/c/761876c857cb2ef8489fbee01907151da902af91
[124] https://www.mail-archive.com/netdev@vger.kernel.org/msg176130.html
[125] https://git.kernel.org/torvalds/c/174a79ff9515f400b9a6115643dafd62a635b7e6
[126] https://git.kernel.org/torvalds/c/2e674381be84311dc88de61b9c9bb39e67fc4f2c
[127] https://www.mail-archive.com/netdev@vger.kernel.org/msg176130.html
[128] https://docs.google.com/presentation/d/1dwSKSBGpUHD3WO5xxzZWj8awV_-xL-oYhvqQMOBhhtk/edit#slide=id.g203aae413f_0_0
[129] https://git.kernel.org/torvalds/c/39c13c204bb1150d401e27d41a9d8b332be47c49
[130] https://git.kernel.org/torvalds/c/92b31a9af73b3a3fc801899335d6c47966351830
[131] https://git.kernel.org/torvalds/c/aae3dbb4776e7916b6cd442d00159bea27a695c1
[132] https://git.kernel.org/torvalds/c/1ca163afb6fd569b6efdc221954177cba5a02cbc
[133] 
[134] 
[135] https://git.kernel.org/torvalds/c/ccc829ba3624beb9a703fc995d016b836d9eead8
[136] https://trustedcomputinggroup.org/platform-reset-attack-mitigation-specification/
[137] 
[138] https://www.heise.de/news/AMD-Ryzen-Pro-AM4-Prozessoren-fuer-Business-PCs-3759324.html
[139] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1491782.html
[140] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1493907.html
[141] https://www.heise.de/news/AMD-Zen-RAM-Verschluesselung-fuer-virtuelle-Maschinen-3315469.html
[142] https://git.kernel.org/torvalds/c/b1b6f83ac938d176742c85757960dec2cf10e468
[143] https://git.kernel.org/torvalds/c/21729f81ce8ae76a6995681d40e16f7ce8075db4
[144] https://git.kernel.org/torvalds/c/7f8b7e7f4ccbbd1fb8badddfabd28c955aea87b4
[145] https://git.kernel.org/torvalds/c/77bd2342d4304bda7896c953d424d15deb314ca3
[146] https://git.kernel.org/torvalds/c/5868f3651fa0dff96a57f94d49247d3ef320ebe2
[147] https://git.kernel.org/torvalds/c/f7750a79568788473c5e8092ee58a52248f34329
[148] https://git.kernel.org/torvalds/c/8f716c9b5febf6ed0f5fedb7c9407cd0c25b2796
[149] https://git.kernel.org/torvalds/c/872cbefd2d9c52bd0b1e2c7942c4369e98a5a5ae
[150] https://git.kernel.org/torvalds/c/7744ccdbc16f0ac4adae21b3678af93775b3a386
[151] https://git.kernel.org/torvalds/c/c7753208a94c73d5beb1e4bd843081d6dc7d4678
[152] https://git.kernel.org/torvalds/c/6ebcb060713f614c92216482eed501b31cee74ec
[153] https://git.kernel.org/torvalds/c/aca20d5462149333ba8b24a4a352be5b7a00dfd2
[154] https://git.kernel.org/torvalds/c/d0ec49d4de90806755e17289bd48464a1a515823
[155] https://git.kernel.org/torvalds/c/c262f3b9a3246da87c66ce398cd7e30d8f1529ea
[156] http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
[157] https://lwn.net/Articles/686808/
[158] 
[159] https://git.kernel.org/torvalds/c/9225331b310821760f39ba55b00b8973602adbb5
[160] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3771362.html?#randstruct
[161] https://git.kernel.org/torvalds/c/44ccba3f7b230af1bd7ebe173cbf5803df1df486
[162] https://git.kernel.org/torvalds/c/f7dd2507893cc3425d3ffc2369559619960befb0
[163] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3641334.html
[164] 
[165] https://git.kernel.org/torvalds/c/8db6c34f1dbc8e06aa016a9b829b06902c3e1340
[166] https://git.kernel.org/torvalds/c/8db6c34f1dbc8e06aa016a9b829b06902c3e1340
[167] https://lwn.net/Articles/726816/
[168] 
[169] https://git.kernel.org/torvalds/c/79444df4e7f03843be78e4b9188d095931648842
[170] https://git.kernel.org/torvalds/c/2ea3ffb7782a84da33a8382f13ebd016da50079b
[171] https://git.kernel.org/torvalds/c/cd1dbf76b23d5ab2cba5e657fe20b1e236a408cc
[172] https://git.kernel.org/torvalds/c/651e28c5537abb39076d3949fb7618536f1d242e
[173] https://git.kernel.org/torvalds/c/80c094a47dd4ea63375e3f60b5e076064f16e857
[174] https://lkml.org/lkml/2017/10/3/1
[175] https://git.kernel.org/torvalds/c/80cee03bf1d626db0278271b505d7f5febb37bba
[176] https://git.kernel.org/torvalds/c/720419f01832f7e697cb80480b97b2a1e96045cd
[177] https://www.heise.de/news/AMD-Treiber-Radeon-Pro-17-8-fuer-Vega-Hardware-Sicherheit-und-On-the-Fly-Treiberwechsel-3784816.html
[178] https://git.kernel.org/torvalds/c/73ac5d6a2b6ac3ae8d1e1818f3e9946f97489bc9
[179] https://git.kernel.org/torvalds/c/cf7de27ab35172a9240f079477cae3146a182998
[180] https://git.kernel.org/torvalds/c/5ea0727b163cb5575e36397a12eade68a1f35f24
[181] https://git.kernel.org/torvalds/c/828f4257d1d33aed0f9ef82982dcb8ace8b7fe86
[182] https://git.kernel.org/torvalds/c/c0a3a64e723324ae6dda53214061a71de63808c3
[183] https://git.kernel.org/torvalds/c/c0a3a64e723324ae6dda53214061a71de63808c3
[184] https://git.kernel.org/torvalds/c/7f85565a3f7194b966de71926471d69788b6b9c3
[185] https://git.kernel.org/torvalds/c/95d3652eec4103977ac96a86f46fa589f7abe012
[186] https://git.kernel.org/torvalds/c/428490e38b2e352812e0b765d8bceafab0ec441d
[187] 
[188] https://git.kernel.org/torvalds/c/8cfd8147df67e741d93b8783a3ea8f3c74f93a0e
[189] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-3-12-3132326.html
[190] https://lwn.net/Articles/729215/
[191] 
[192] https://git.kernel.org/torvalds/c/bffc33ec539699f045a9254144de3d4eace05f07
[193] https://lwn.net/Articles/684916/
[194] 
[195] https://git.kernel.org/torvalds/c/3ee31b89d9b12c01aa03dda7a923ef07a800eedd
[196] https://xenbits.xen.org/docs/unstable/misc/pvcalls.html
[197] https://git.kernel.org/torvalds/c/72e59c30df449bc7fe601716e60c824b4ffe606d
[198] https://git.kernel.org/torvalds/c/42d3078a8ad7542eee980da08a781a769bb21fe4
[199] https://blog.xenproject.org/2016/08/30/pv-calls-a-new-paravirtualized-protocol-for-posix-syscalls/
[200] https://git.kernel.org/torvalds/c/ae0078fcf0a5eb3a8623bfb5f988262e0911fdb9
[201] https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/user-guide/make-integration-service
[202] https://git.kernel.org/torvalds/c/0756b7fbb696d2cb18785da9cab13ec164017f64
[203] https://git.kernel.org/torvalds/c/9db59599ae502b38b27cff6462273f84acd59927
[204] 
[205] https://git.kernel.org/torvalds/c/674e75411fc260b0d4532701228cfe12fc090da8
[206] https://git.kernel.org/torvalds/c/99d14d0e16fadb4de001bacc0ac0786a9ebecf2a
[207] https://git.kernel.org/torvalds/c/c49cbc19b31e069cb344921c7286d7549767d10e
[208] httphes://lwn.net/Articles/732740/
[209] https://git.kernel.org/torvalds/c/f213a6c84c1b4b396a0713ee33cff0e02ba8235f
[210] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1463003.html
[211] https://git.kernel.org/torvalds/c/bd4c82c22c367e068acb1ec9ec02be2fac3e09e2
[212] https://git.kernel.org/torvalds/c/493b0e9d945fa9dfe96be93ae41b4ca4b6fdb317
[213] https://git.kernel.org/torvalds/c/c9bff3eebc09be23fbc868f5e6731666d23cbea3
[214] https://git.kernel.org/torvalds/c/cbc65df240c104bf540af1ad58595bf1eaa5ee10
[215] https://git.kernel.org/torvalds/c/d9bfcfdc41e8e5d80f7591f95a09ccce7cb8ad05
[216] https://git.kernel.org/torvalds/c/ec560175c0b6fce86994bdf036754d48122c5c87
[217] https://git.kernel.org/torvalds/c/a2468cc9bfdff6139f59ca896671e5819ff5f94a
[218] https://git.kernel.org/torvalds/c/bd4c82c22c367e068acb1ec9ec02be2fac3e09e2
[219] https://lwn.net/Articles/728795/
[220] https://git.kernel.org/torvalds/c/22e4ebb975822833b083533035233d128b30e98f
[221] https://git.kernel.org/torvalds/c/cd9e61ed1eebbcd5dfad59475d41ec58d9b64b6a
[222] https://git.kernel.org/torvalds/c/81a84ad3cb5711cec79f4dd53a4ce026b092c432
[223] https://git.kernel.org/torvalds/c/0c0b6b7bc427caed77b172916edc3c36cd1ab79d
[224] https://git.kernel.org/torvalds/c/0e3258753f8183c63bf68bd274d2cc7e71e5f402
[225] https://git.kernel.org/torvalds/c/ec11653b531099ddc08a8c7eb495ab83cae84e19
[226] https://git.kernel.org/torvalds/c/80aafd50b6a4fa6b6bba4b451b553d5d221f59ff
[227] https://git.kernel.org/torvalds/c/706eeb3e9c6f032f2d22a1c658624cfb6ace61d4
[228] https://git.kernel.org/torvalds/c/4de5f89ef8498e012ba4755b9b63df28c1382690
[229] https://git.kernel.org/torvalds/c/f1824df12ecd495b25c8c116876e201ac764ecea
[230] https://git.kernel.org/torvalds/c/b09be676e0ff25bd6d2e7637e26d349f9109ad75
[231] https://git.kernel.org/torvalds/c/ef0758dd0fd70b98b889af26e27f003656952db8
[232] https://git.kernel.org/torvalds/c/9657752cb5039c7498d4b27c4a75530f93b87d9b
[233] https://git.kernel.org/torvalds/c/60f83fa6341dab4aec01cee354ea902771473adb
[234] https://git.kernel.org/torvalds/c/8d51735fcd2be1791c0bfe2d581d9063281fe7fb
[235] https://git.kernel.org/torvalds/c/b851dd49868e295e18c5d72fc3bad85ff1c444b1
[236] https://git.kernel.org/torvalds/c/d5c7f9dc58edcfb6b45f557bb0023173a0dabde6
[237] https://git.kernel.org/torvalds/c/c35aeb9dfe512422ca9ea28aae692c8f1d052b2d
[238] https://git.kernel.org/torvalds/c/49d58f04eb6cdc18b3747fc4243a7114364f5420
[239] https://git.kernel.org/torvalds/c/8780fb25ab060bafa5a8149e79b703e0fc7ee847
[240] https://git.kernel.org/torvalds/c/3b0a5daa061076b2b75ffc294e74483ad9bf241a
[241] https://git.kernel.org/torvalds/c/fc7ce9c74c3ad232b084d80148654f926d01ece7
[242] https://git.kernel.org/torvalds/c/7e63a13a266da652f82731b845b5c35dd866ec7e
[243] https://en.wikichip.org/wiki/macro-operation_fusion
[244] https://git.kernel.org/torvalds/c/53ac64aac9af8cd0e5456c8a9bb68c47b571b0a9
[245] https://git.kernel.org/torvalds/c/608c1d3c17e9e0e87dae69b9bb78f0556006ee6e
[246] https://git.kernel.org/torvalds/c/74fee4e88fd196c712abfdae89acfa272abf10f8
[247] https://git.kernel.org/torvalds/c/e7d0c41ecc2e372a81741a30894f556afec24315
[248] https://git.kernel.org/torvalds/c/f92e3da18b7d5941468040af962c201235148301
[249] https://git.kernel.org/torvalds/c/4dfc2788033d30dfccfd4268e06dd73ce2c654ed
[250] https://git.kernel.org/torvalds/c/a2bc8dea9e96872e16248884367ad0013e040089
[251] https://git.kernel.org/torvalds/c/6d6218976df142ba5594371f8dbd56650151c56f
[252] https://git.kernel.org/torvalds/c/5f82e71a001d14824a7728ad9e49f6aea420f161
[253] https://git.kernel.org/torvalds/c/0d519f2d1ed1f11e49abc88cfcf6cf13b83ba14c
[254] https://git.kernel.org/torvalds/c/a7cbfd05f427f8f1164bc53866971e89a0cbe103
[255] https://git.kernel.org/torvalds/c/439644096c1a6afb9bd9953130f4444a856f76c5
[256] https://git.kernel.org/torvalds/c/c971aa3693e1b68086e62645c54a087616217b6f
[257] https://git.kernel.org/torvalds/c/0081a0ce809b611c1f37da5d6ae5bc8027ffd1c4
[258] https://git.kernel.org/torvalds/c/8c1d70b2de517e7b44dcac24416e60c9662db507
[259] 
[260] https://git.kernel.org/torvalds/c/e90937e756938f03d37d4cae7c82316a3a425944
[261] https://git.kernel.org/torvalds/c/10af6235e0d327d42e1bad974385197817923dc1
[262] https://git.kernel.org/torvalds/c/0790c9aad84901ca1bdc14746175549c8b5da215
[263] https://git.kernel.org/torvalds/c/57e88b43b81301d9b28f124a5576ac43a1cf9e8d
[264] https://git.kernel.org/torvalds/c/6a8edbd0c54ae266b12f4f63e406313481c9d4bc
[265] https://git.kernel.org/torvalds/c/806c89273bab0c8af0202a6fb6279f36042cb2e6
[266] https://git.kernel.org/torvalds/c/628f54cc6451d2706ba8a56763dbf93be02aaa80
[267] https://git.kernel.org/torvalds/c/2ffd9e33ce4af4e8cfa3e17bf493defe8474e2eb
[268] https://git.kernel.org/torvalds/c/79c2a9d33a04a5ad0df4e926427f3aaf153cc4a4
[269] https://git.kernel.org/torvalds/c/2c7c040c73e9e5686a5b451674b0592551a52345
[270] https://git.kernel.org/torvalds/c/6235a80a5475d10ebef646c06cf7cf0f4aba688c
[271] https://git.kernel.org/torvalds/c/f4ff257cd1607ef79f6647a633d6cc495529cbff
[272] https://git.kernel.org/torvalds/c/359b5a1e1c2d81af6d68de509e11d08ab4c150dc
[273] https://git.kernel.org/torvalds/c/ee89252b9edf08a8be3a4f5db53c56d39c872822
[274] https://git.kernel.org/torvalds/c/8fac2f96ab86b0e14ec4e42851e21e9b518bdc55
[275] https://git.kernel.org/torvalds/c/ae46654bcff303b33facbbd04a3ad9c21d303f9b
[276] https://git.kernel.org/torvalds/c/e90937e756938f03d37d4cae7c82316a3a425944
[277] https://git.kernel.org/torvalds/c/7f1b9be13a7dbe8e51ea541bbcd6c47adae39c71
[278] https://git.kernel.org/torvalds/c/04759194dc447ff0b9ef35bc641ce3bb076c2930
[279] https://git.kernel.org/torvalds/c/7318413077a5141a50a753b1fab687b7907eef16
[280] https://git.kernel.org/torvalds/c/f32c9e059eb6c12a4296003489b167f8eef9d201
[281] https://git.kernel.org/torvalds/c/bac65d9d87b383471d8d29128319508d71b74180
[282] https://git.kernel.org/torvalds/c/9e85ae6af6e907975f68d82ff127073ec024cb05
[283] https://git.kernel.org/torvalds/c/260d16580db018e3faeb1992c70c13bf00e726b8
[284] https://git.kernel.org/torvalds/c/d719518d9ce9132bad8a06e8029aeead328f66a3
[285] https://git.kernel.org/torvalds/c/b0c79f49c343cda8954b3322984c32f258ca4ccb
[286] https://git.kernel.org/torvalds/c/f57091767add2b79d76aac41b83b192d8ba1dce7
[287] https://git.kernel.org/torvalds/c/7031b6412586e0f8543039257f457e183aeb463c
[288] https://git.kernel.org/torvalds/c/b1b6f83ac938d176742c85757960dec2cf10e468
[289] 
[290] 
[291] https://git.kernel.org/torvalds/c/cf2f0a372049451eb824982b7fb26b1a15097821
[292] https://git.kernel.org/torvalds/c/a0aeb3b2ac3ff0608f1bc3fb46332148856d3276
[293] https://rocm.github.io/
[294] https://lists.freedesktop.org/archives/amd-gfx/2017-September/013609.html
[295] https://www.heise.de/news/Ryzen-Mobile-AMDs-grosser-Schritt-zurueck-in-den-Notebook-Markt-3873987.html
[296] https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg197180.html
[297] 
[298] https://git.kernel.org/torvalds/c/cf6e7bac6357f0ccca51fcb5eb325e724f6b4c95
[299] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3283402.html
[300] https://lists.freedesktop.org/archives/dri-devel/2017-October/154486.html
[301] 
[302] https://git.kernel.org/torvalds/c/2659b4ce284be569b06ea2c13e5d30517f8095ed
[303] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
[304] 
[305] https://git.kernel.org/torvalds/c/15b4511a4af633dca0762ae5646fdf05f1dea99a
[306] https://de.wikipedia.org/wiki/Consumer_Electronics_Control
[307] https://git.kernel.org/torvalds/c/906dde0f355bd97c080c215811ae7db1137c4af8
[308] https://git.kernel.org/torvalds/c/c1c026dbc183497379502496316d5e2a22876b7e
[309] https://git.kernel.org/torvalds/c/eac99d4a2013d9e68d12d8a5695b221593d3aa8d
[310] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3641334.html
[311] https://git.kernel.org/torvalds/c/503f04530fec97f93673ae9048b5312cc4455cfe
[312] 
[313] https://git.kernel.org/torvalds/c/2357f6f00098a437f9de084c3c34254d20dea789
[314] https://git.kernel.org/torvalds/c/a838dcc286754f6ea6bcbee8eb76a5d626642fa7
[315] https://git.kernel.org/torvalds/c/b003a345dc67c7a1c468ad8ff10b24d7dd12e12c
[316] https://git.kernel.org/torvalds/c/86d7ce3dd717e09a442d35dae3f9c62c03e024d8
[317] https://git.kernel.org/torvalds/c/cb6a552846297094aac942a588fe7ed7922a6c11
[318] https://git.kernel.org/torvalds/c/c0da4fa0d1a54495d6055c009ac46b76d1da2c86
[319] https://git.kernel.org/torvalds/c/cd21b334943719f880e707eb91895fc916a88000
[320] https://git.kernel.org/torvalds/c/44173fda45ba25af84ae5c3e9b745bb286163730
[321] https://git.kernel.org/torvalds/c/3c4e04153f9aacfb34e8c5c884c1424e08994aaf
[322] https://git.kernel.org/torvalds/c/bb4cec96e5d7f0ff7f397f4518399be77a2f12db
[323] https://git.kernel.org/torvalds/c/df3082df7da27b66ea2f2cb2350781fd18c1a220
[324] https://git.kernel.org/torvalds/c/48f76b68f9fca4e1d5bbb1755d14e8e8e09bdd5b
[325] https://git.kernel.org/torvalds/c/5b5ab4cb5cda824ef59e0511ac5d585f35f1a1a6
[326] http://cateee.net/lkddb/
[327] https://git.kernel.org/torvalds/c/957b8dffa4e3d191f0f1571d006d0e520790dcb9
[328] https://git.kernel.org/torvalds/c/57573c541be6c7bca5c27427a5f908d8a22d0b00
[329] https://git.kernel.org/torvalds/c/991368818df4a50f50d2ce673b308f946ed635a6
[330] https://git.kernel.org/torvalds/c/bafb0762cb6a906eb4105cccfb3bcd90be7f40d2
[331] https://git.kernel.org/torvalds/c/44b1671fae88ce95b8c7b53acbc6ba71ca67db00
[332] https://git.kernel.org/torvalds/c/9d71941d39fb876271df72394518a98ae079e5a3
[333] https://git.kernel.org/torvalds/c/c8503720fd0b952ff25bcc49b6eb9c492e22f3c6
[334] https://git.kernel.org/torvalds/c/b42a362e6d10c342004b183defcb9940331b6737
[335] https://git.kernel.org/torvalds/c/fe91f28138e730790db014812623cfaadd318fa6
[336] https://git.kernel.org/torvalds/c/0e271fd59fe9e6d8c932309e7a42a4519c5aac6f
[337] https://git.kernel.org/torvalds/c/aa9d4648c2fbb455df7750ade1b73dd9ad9b3690
[338] https://git.kernel.org/torvalds/c/d969443064abf2f51510559a5b01325eaabfcb1d
[339] https://git.kernel.org/torvalds/c/bf1d6b2c76eda86159519bf5c427b1fa8f51f733
[340] https://git.kernel.org/torvalds/c/e63a94f12b5fc67b2b92a89d4058e7a9021e900e
[341] https://git.kernel.org/torvalds/c/1a3b85ea36d38d5732fdd86b321b10bcaeb53512
[342] https://git.kernel.org/torvalds/c/939ae58960bb5ce0c51776aec38877a401c03bcf
[343] https://git.kernel.org/torvalds/c/b38923a068c10fc36ca8f596d650d095ce390b85
[344] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
[345] 
[346] https://www.kernel.org/doc/html/latest/process/kernel-enforcement-statement.html
[347] https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering
[348] http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
[349] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/CREDITS
[350] https://marc.info/?l=netfilter-devel&m=146887464512702
[351] https://www.netfilter.org/files/statement.pdf
[352] http://www.netfilter.org/licensing.html#faq
[353] https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering
[354] https://lwn.net/Articles/694890/
[355] https://lwn.net/Articles/721458/
[356] http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
[357] http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
[358] https://git.kernel.org/torvalds/c/3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11
[359] 
[360] https://spdx.org/
[361] https://git.kernel.org/torvalds/c/ead751507de86d90fa250431e9990a8b881f713c
[362] https://en.wikipedia.org/wiki/License_compatibility
[363] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING
[364] 
[365] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1535185.html
[366] https://riscv.org/
[367] https://www.heise.de/news/RISC-V-mit-64-Bit-Architektur-als-IP-Core-lieferbar-3853610.html
[368] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3283402.html
[369] 
[370] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3217845.html
[371] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3283402.html
[372] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3351436.html
[373] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3596869.html
[374] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3641334.html
[375] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3712705.html
[376] https://www.heise.de/hintergrund/Die-Neuerungen-von-Linux-4-6-3771362.html
[377] https://kernel.org/
[378] https://www.heise.de/tests/Linux-Kernel-massgeschneidert-1402386.html
[379] 
[380] mailto:thl@ct.de

Copyright © 2017 Heise Medien