Logo von c't

Suche
Abonnieren

Tägliche Top-News bei WhatsApp, Facebook Messenger, Telegram & Insta

preisvergleich_weiss

Recherche in 1.508.171 Produkten

Thorsten Leemhuis 74

Die Neuerungen von Linux 4.11

Linux-Kernel 4.11

Die neue Kernel-Version unterstützt moderne Stromspartechniken besser und kann so die Akkulaufzeit steigern. Die Entwickler haben Grundlagen gelegt, um auf x86-64-Systemen bald bis zu 1 Petabyte Arbeitsspeicher ansprechen zu können. Die nächste Kernel-Version bringt zudem eine Technik, um die 3D-Beschleunigung von Radeon-GPUs in VMs nutzen zu können. Auch die Unterstützung für den Raspberry Pi wird besser.

Linus Torvalds hat Linux 4.11 freigegeben. Wie bei den vorangegangenen Kernel-Versionen dauerte die Entwicklung auch diesmal wieder zehn Wochen. Das ist abermals etwas länger als vor ein bis drei Jahren üblich, denn damals dauerte die Entwicklung einer neuen Version typischerweise neun Wochen; zweimal waren es sogar nur acht.

Wie gewohnt bringt die neue Linux-Version zahlreiche Neuerungen. Die wichtigsten im Kurzüberblick:

Das sind lediglich die Eckdaten der wichtigsten Änderungen; der Rest dieses Kernel-Logs liefert Details zu diesen und vielen weiteren Neuerungen.

Die Akkus vieler mit NVMe-SSDs ausgerüsteten Notebooks dürften unter Linux 4.11 länger durchhalten, denn das NVMe-Subsystem nutzt jetzt automatisch APST (Autonomous Power State Transitions) (1, 2). Durch diese Stromspartechnik gehen NVMe-Datenträger autark schlafen, wenn es gerade nichts zu tun gibt. Das spart oft zwischen 0,5 und 1,0 Watt – das senkt die Leerlauf-Leistungsaufnahme sparsamer Notebooks um 20 bis 30 Prozent und verlängert die Akkulaufzeit so spürbar.

Der Kernel hat APST bislang nicht aktiviert, weil sie bei manchen SSDs zu Abstürzen und Datenverlust führen kann. Nach aktuellem Kenntnisstand sind davon die Toshiba XG4 (THNSF5256GPUK) und die Samsung SM951 betroffen – letztere allerdings nur bei bestimmten Geräten. Bei diesen NVMe-SSDs nutzt Linux die Stromspartechnik daher nach wie vor nicht.

APST führt bei der Samsung SM951 zu Problemen. Bild: Commit auf git.kernel.org

Das Abklären des Datenverlustrisikos war einer der Gründe, warum die APST-Unterstützung nicht eher eingepflegt wurde. Die Änderungen zirkulieren nämlich schon seit einem halben Jahr und werden in Wikis, Foren und anderen Stellen gelegentlich empfohlen, um die Laufzeit von Notebooks zu steigern.

Nach wie vor ungelöst sind indes Datenverlustprobleme einiger Patches, die einen moderneren Weg bei der Konfiguration der AHCI-Stromspartechnik ALPM (Aggressive Link Power Management) implementieren. Aus diesem Grund dürften die Änderungen noch eine Weile oder womöglich für immer außen vor bleiben, obwohl sie die Leistungsaufnahme von Notebooks mit SATA-Datenträgern oft signifikant reduzieren.

Über Linux 4.11 lässt sich die Verschlüsselungsfunktion von SSDs nutzen, welche die Opal Storage Specification der Trusted Computing Group (TCG) implementieren. Bei solchen Self-Encrypting Drives (SED) verschlüsselt die SSD die Daten selbst. Das kann Lebensdauer und Performance steigern, weil Mechanismen wie Wear Leveling und Trim besser greifen; außerdem entlastet es den Hauptprozessor. Bitlocker nutzt daher bei einigen der modernen Windows-Versionen die Selbstverschlüsselung mit Opal-Hilfe automatisch, wenn der Anwender die Verschlüsselungs-Software aktiviert. So konfigurierte Datenträger nennt Microsoft dann Encrypted Hard Drive (eDrive).

Linux unterstützt jetzt das bei selbstverschlüsselnden SSDs eingesetzte Opal.

Per Opal lässt sich die Speicherkapazität in Segmente aufteilen; diese "Speicherbänder" können unterschiedliche Schlüssel haben oder gänzlich unverschlüsselt sein. Im unverschlüsselten Bereich landet bei Boot-Datenträgern oft die ESP (EFI System Partition) samt des darin befindlichen Boot-Codes. Letzterer gibt das verschlüsselte Speicherband frei. Dazu fragt der Code ein Passwort ab oder liest einen Schlüssel von USB-Stick oder TPM. Neben der neuen Opal-Unterstützung im Linux-Kernel sind daher auch Userspace-Werkzeuge nötig, um Speicherbänder zu entsperren und Opal-SEDs anderweitig zu administrieren. Es ist ungewiss, wann Linux-Distributionen diese Werkzeuge mitbringen und idealerweise auch so integrieren, dass Anwender sich nicht mit Interna auseinandersetzen müssen.

GPU-Virtualisierung bei AMD

Der Grafiktreiber Amdgpu enthält beispielsweise eine rudimentäre und noch nicht alltagstaugliche Infrastruktur zur GPU-Virtualisierung. Damit kann der Kernel-Treiber Teile von professionellen AMD-GPUs als virtuelle Geräte bereitstellen, die sich an virtuelle Maschinen (VMs) überstellen lassen. Das darin laufende Betriebssystem kann die GPU darüber ohne sonderlichen Geschwindigkeitsverlust nutzen ohne den Host zu gefährden (u. a. 1, 2, 3, 4, 5). Selbst Spiele und 3D-Anwendungen, die in einer Windows-VM auf einem Linux-Host laufen, sollten so ordentliche Performance liefern. Das Ganze ist aber auch zum Einsatz von GPUs zu Rechenzwecken (GPGPU/General-purpose Computing on Graphics Processing Units) oder zur Desktop-Virtualisierung interessant; bei Letzterer greifen Anwender über Thin-Clients beispielsweise auf den Desktop eines Windows zu, das im Rechenzentrum in einer VM läuft.

Dies war ein schrittweise aktualisierter Artikel

Dieser Text wurde mehrfach erweitert, um nach und nach alle wesentlichen Änderungen Linux 4.11 zu beschreiben. Zur jüngst erfolgten Freigabe dieser Version haben wir die Absätze 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.

AMD überstellt Teile der GPU mit Hilfe von SR-IOV (Single-root Input/Output Virtualization), das derzeit nur einige der professionellen AMD-Grafikkarten der FirePro-Reihe bieten; Mainstream-Grafikkarten sollen die Funktion aber auch bald erhalten. SR-IOV wird schon seit Jahren bei Netzwerkchips eingesetzt; mit ihr exportiert der Ethernet-Adapter Teilfunktionen seiner selbst als virtuelle Netzwerk-Devices, die sich an VMs überstellen lassen, wo sie wie vollwertige Ethernet-Schnittstellen bereitstehen.

Der Nouveau-Treiber kann durch einige Umbauten nun die Firmware-Dateien handhaben, die Nvidia kürzlich für seine Pascal-GPUs der ersten Generation veröffentlicht hat (u. a. 1, 2, 3). Mit diesen jüngst in linux-firmware eingeflossenen Firmware-Dateien wird sich bald die 3D-Beschleunigung bei den GP1xx-GPUs der GeForce-1000-Reihe nutzen lassen. Bei 4.11 funktioniert das aber noch nicht, denn die Änderungen zur Nutzung der 3D-Beschleunigung wurden zu spät fertig und folgen erst bei 4.12.

Bisher ließ sich die 3D-Beschleunigung bei der GeForce-1000-Serie nicht mit quelloffenen Treiber verwenden: Nvidias moderne GPUs enthalten eine Sicherheitstechnik, durch die sich viele Funktionen der Grafikprozessoren ausschließlich mit einer von Nvidia signierten Firmware verwenden lassen. Für die Open-Source-Gemeinde veröffentlicht Nvidia allerdings eine spezielle Firmware. Genau wie bei der Firmware für die GPUs der GeForce-900er-Reihe ermöglicht allerdings auch die GP1xx-Firmware bislang keinen Wechsel der Geschwindigkeitsstufe. Die schnellsten Betriebszustände lassen sich daher ebensowenig nutzen wie die stromsparendsten; vielmehr laufen GPUs und Speicher mit den beim Booten von der Firmware gesetzten Taktfrequenzen. Nvidia macht es den freien Treibern so unmöglich, das Performance-Niveau zu erreichen, das Nvidias proprietäre Linux-Treiber erzielen.

Durch AppArmor-Verbesserungen dürften Snaps mittelfristig bei mehr Distributionen abgeschottet laufen. Bild: github.com/snapcore/snapd/ (5.4.2017)

Nachdem es in den Jahren 2014 und 2015 nur eine Handvoll von Änderungen am Kernel-Code der Sicherheitslösungen AppArmor gab, hat dessen Entwicklung im letzten Jahr wieder etwas an Fahrt aufgenommen. Das setzt sich mit 4.11 fort, denn diesmal gab es über sechzig Änderungen; das sind mehr als im ganzen Jahr 2016. Durch die neuesten Anpassungen unterstützt der Kernel nun Policy Namespaces und einige andere Funktionen, mit denen die Werkzeuge zum Betrieb von Snaps die darin enthaltene Software im Betrieb abschirmen; weitere dafür nötige Änderungen sollen in die beiden nächsten Kernel-Versionen einfließen. Die zum abgeschirmten Betrieb von Snaps nötigen Schutztechniken finden sich bislang nur in den Kerneln von Ubuntu; auf nahezu allen anderen Distributionen laufen Snaps daher derzeit ohne die Abschottung, die zu einer der Haupteigenschaften des mit Flatpak konkurrierenden Paketformats zählen.

Beim in Linux 3.17 integrierten Multi-Queue Block IO Queueing Mechanism (Blk-Mq) können sich nun I/O-Scheduler einklinken. Solche können die gerade anstehenden Lese- und Schreiboperationen umsortieren oder zusammenfassen, um die Performance zu verbessern – beispielsweise indem sie die Wege reduzieren, die Schreib-/Leseköpfe von Festplatten nehmen müssen. Solche Kopfbewegungen kosten viel Zeit, daher sind I/O-Scheduler für Festplatten deutlich wichtiger als für SSDs.

Bei der alten, von manchen Storage-Treibern nach wie vor genutzten Block-Layer-Infrastruktur kamen typischerweise I/O-Scheduler wie CFQ (Completely Fair Queuing) und Deadline zum Einsatz. Beim mittelfristig als Nachfolger vorgesehen Blk-Mq gab es solche bislang nicht, denn es wurde vornehmlich für Storage-Controller und Datenträger mit mehreren Warteschlangen entwickelt. Solche Hardware kann im Idealfall mehrere Operationen parallel verarbeiten und dabei autark umsortieren; ein Scheduler im Kernel kann dann Overhead oder sogar kontraproduktiv sein.

Manche Storage-Treiber nutzen Blk-mq mittlerweile auch für Hardware, wo der Einsatz eines I/O-Scheduler Vorteile bietet. Die Entwickler haben daher jetzt eine Infrastruktur für solche nachgerüstet und zugleich den darauf aufbauenden Scheduler Mq-Deadline integriert (1, 2). Letzterer arbeitet ähnlich wie der klassische Deadline Scheduler der älteren Block-Layer-Infrastruktur. Bei Linux 4.12 soll eine auf Blk-Mq angepasste Variante des Budget Fair Queueing (BFQ) Storage-I/O Scheduler folgen. Er ist vor Jahren aus CFQ hervorgegangen; wurde aber grundlegend überarbeitet und soll bessere Performance liefern. Bislang baute BFQ auf der älteren Block-Layer-Infrastruktur auf; seine Entwickler wollen den Scheduler schon länger in den offiziellen Linux-Kernel einbringen, sind aber immer wieder gescheitert.

Der neue Syscall "statx()". Bild: Commit auf git.kernel.org

An Programmierer richtet sich der neue System-Funktionsaufruf statx(), der eine umfassendere und effizientere Abfrage von Datei- oder Verzeichniseigenschaften ermöglicht. Der neue Syscall versucht stat() und fstat() zu beerben, über die Anwendungen bislang Größe, Berechtigungen, Attribute und zahlreiche andere Informationen zu Dateisystemeinträgen abfragen. Mithilfe des bereits 1971 mit der ersten Unix-Version definierten und seitdem kaum veränderten stat() lassen sich aber einige bei modernen Systemen relevante Eigenschaften nicht abrufen. In diese Klasse fallen Informationen wie "ist die Datei verschlüsselt", "liegt die Datei remote", "welche Version hat die Datei" oder "wann wurde der Dateisystemeintrag erzeugt"; außerdem haben die Zeitstempel ein Jahr-2038-Problem. Der neue Funktionsaufruf liefert die Details und kann zudem die Performance steigern: Programme können bei der Abfrage gezielt festlegen, welche Informationen sie interessieren; Dateisysteme können sich dadurch sparen, letztlich ohnehin ignorierte Daten zusammenzusuchen und weiterzugeben.

Der Entwickler von statx() hat bereits 2010 an der Arbeit für den jetzt integrierten Syscall begonnen. Die Umsetzung hat sich aber hingezogen, weil die Arbeit zeitweise zurückgestellt wurde; außerdem haben andere Entwickler zahlreiche Wünsche geäußert, durch die die jetzt aufgenommene Implementation nur noch wenig mit dem ursprünglich geplanten Ansatz gemein hat. Damit sich statx()nutzen lässt, muss das Dateisystem den Syscall aber auch implementieren; bei Ext4 soll das schon bald der Fall sein. Details zum neuen Funktionsaufruf finden sich in einem LWN.net-Artikel und dem Commit-Kommentar zu statx().

Linux 4.11 enthält Grundlagen, durch die 4.12 auf x86-64-Systemen bis zu 4096 Terabyte Speicher ansprechen können soll – "genug für jeden", scherzt der Entwickler in Anspielung auf das vermeintliche Bill-Gates-Zitat "640 kB sollten eigentlich genug für jeden sein." Bild: LKML-Post auf mail-archive.com

Die Kernel-Entwickler haben erste Grundlagen gelegt, mit denen Linux bald auf x86-64-Systemen bis zu 4 Petabyte (4096 Terabyte) Arbeitsspeicher adressieren kann. Die auf dem jetzt gelegten Fundament aufbauenden Patches zur Unterstützung von so viel RAM sollen bei 4.12 folgen, wenn alles gut geht. Bislang ist auf x86-64-Systemen bei 64 Terabyte Arbeitsspeicher Schluss; eine Grenze, an die einige Hardware-Hersteller mit ihren Servern gerade stoßen. Weitere Hintergründe zu den vorgenommenen und den vorbereiteten Änderungen zur Unterstützung von mehr Arbeitsspeicher liefert ein LWN.net-Artikel.

Einige Umbauten am Speichermanagement-Code versprechen die Swap-Performance leistungsstarker Systeme zu verbessern (u.a. 1, 2, 3, 4, 5). Die Änderungen steigern vor allem die Skalierbarkeit und wurden von Intel-Mitarbeitern speziell für Mehrprozessor-Systeme mit besonders schnellen Datenträgern entwickelt – also NUMA-Server, in denen PCIe-SSDs oder persistente Memory/NVDIMMs stecken. Solche Datenträger haben einen viel höheren Datendurchsatz als Festplatten; zugleich sind die Zugriffslatenzen um Größenordnungen niedriger. Der Performance-Einbruch durch Swapping ist dadurch längst nicht so krass, wie viele Anwender es vom Auslagern von Arbeitsspeicher auf Festplatten kennen.

Server-Betreiber haben deshalb wieder ein gesteigertes Interesse an Swapping entwickelt. Ein Grund dafür auch: Bei Cloud-Servern ist es beispielsweise üblich, den auf einem Host laufenden Instanzen (VMs, Containern, …) mehr Arbeitsspeicher zuzuteilen, als im jeweiligen Server steckt. Solches Memory Overcommitment drängt sich aus Effizienzgründen geradezu auf, weil längst nicht jede Instanz den ihr zugeteilten Arbeitsspeicher komplett nutzt. Falls der im Cloud-Server verbaute Arbeitsspeicher dann aber doch mal knapp wird, kann Swapping mit schnellen Datenträgern länger sicherstellen, dass der Server seine Aufgaben weiterhin ohne größere Performance-Einbußen wahrnimmt. Außerdem können so im Swap-Space auch Speicherinhalte landen, den Instanzen ohnehin nur selten ansprechen.

TCP Fast Open (TFO), mit dem Programme seit Linux 3.13 den Aufbau von HTTP-Verbindungen beschleunigen können, lässt sich jetzt über ein weiteres API nutzen. Dieses soll Vorteile für Anwendungen bieten, die gleich nach dem Verbindungsaufbau Daten per write() senden.

Die bei Linux 3.5 integrierte Unterstützung für das in RFC5827 definierte TCP Early Retransmit haben die Entwickler entfernt: Durch Verbesserungen am bei Linux 4.4 eingeführten Package-Loss-Algorithmus RACK (Recently ACK) sei die Funktion jetzt unnötig. Beide Techniken versprechen einen Geschwindigkeitszuwachs bei TCP-Verbindungen, bei denen häufiger Netzwerkpakete verloren gehen.

Airtime Fairness Scheduling im Ath9k-Treiber verspricht bessere Effizienz in Netzen mit mehreren aktiven Stationen. Bild: git.kernel.org

Durch neue und verbesserte Treiber unterstützt der Kernel nun auch den Wi-Fi System-On-Chip (WiSoC) RaLink RT5350, der vor allem in Routern steckt. Der Treiber ath9k beherrscht jetzt "airtime fairness scheduling", das die Effizienz steigern kann, wenn mehrere Geräte parallel im Netz funken. Der QLogic-4xxx-Treiber "qed" kann nun Hardware Offloading für FCoE (Fibre Channel over Ethernet) nutzen und so den Hauptprozessor entlasten.

Über den neuen Treiber "ipvtap" lassen sich nun Ipvlan-Netzwerkschnittellen einrichten, die sich mit den bekannten Userspace-Tools für TAP-Devices administrieren lassen; um letzteres zu ermöglichen, wurde der Code für virtuelle Netzwerkadapter des Typs "TAP" modularisiert. Ipvlan wurde bei Linux 3.19 eingeführt und zur Netzwerkverbindung zwischen Containern eines Systems entwickelt.

Über den neuen Generic-Netlink-Channel Psample können Kernel-Module den Netzwerkverkehr untersuchen und klassifizieren. Dadurch soll es beispielsweise möglich werden, bestimmte Pakete mit Hilfe des Traffic-Control-Werkzeug tc samt ihrer Metadaten in den Userspace zu leiten.

Neu dabei, aber nahezu undokumentiert ist der neue Socket Typ "SMC-R". Über dieses als RFC7609 eingereichte Protokoll können mehrere Rechner sich Speicherbereiche über RDMA-Verbindungen teilen (Shared Memory).

Es gab wieder zahlreiche Verbesserungen am BPF. Dadurch lässt sich dieser nun etwa mit Tracepoints überwachen und kann beim Matchen von IP-Adressen über Maps jetzt effizienter arbeiten.

Der Haupt-Git-Pull des Netzwerk-Subsystems nennt einige weitere Änderungen im Netzwerkbereich. Allein dieser Satz von Änderungen enthielt über 1700 Patches, die 1746 Dateien modifiziert haben und die Kernel-Quellen um rund 60.000 Zeilen wachsen ließen.

Die Anpassungen am MD-Subsystems haben eine Dokumentation für den RAID-5-Writeback-Cache nachgerüstet, den Linux 4.10 gebracht hat. Ferner soll der RAID-1-Code durch eine neue I/O Barrier besser skalieren.

Seit Linux 4.4 kann der Kernel einen Datenträger als "Log-Device" an Software-RAIDs der Level 4, 5 und 6 koppeln, um bei Abstürzen die Datenintegrität besser zu gewährleisten. Diese Funktion lässt sich jetzt auch über den Device Mapper nutzen. Unter den anderen Änderungen am von LVM verwendenden Subsystem war ferner ein neues Metadaten-Format für das Cache-Target, das ein Herunterfahren des Cache-Verbunds beschleunigen soll.

Die Änderungen am SCSI-Subsystem (1, 2) haben den Funktionsumfang einer Reihe von Storage-Treibern erweitert. Der Treiber Megaraid-SAS spricht dadurch jetzt einige SAS3.5 Generic Megaraid Controller an. Multi-Queue Support im HyperV-Storage-Treiber verspricht bessere I/O-Performance beim Betrieb unter Microsofts Hypervisoren. Aacraid beherrscht jetzt Hotplug. Der Treiber Qla2xxx kann jetzt gleichzeitig im Initiator- und Target-Mode arbeiten. Lpfc beherrscht nun den Betrieb als NVMe Initiator oder Target. Neu dabei ist ein Treiber für FCoE (Fibre Channel over Ethernet) mit den Converged Network Adapters der 41000er-Serie von QLogic.

Einige weitere Anpassungen am Storage-Support erwähnen die Merge-Kommentare der Subsysteme Block (1, 2), MTD, Libata und SCSI Target

Die Änderungen am CIFS enthielten gleich mehrere Patches eines Microsoft-Mitarbeiters. Durch sie beherrscht das Dateisystem nun Freigaben-spezifische Verschlüsselung (per-share encryption), die das in aktuellen Samba- und Windows-Versionen unterstützte SMB3 ermöglicht (u. a. 1, 2, 3, 4). Durch einen weiteren Satz von Änderungen beherrscht CIFS nun DFS (Distributed File System) auch mit SMB 2.0 und höher.

Das Ext4-Dateisystem kennt jetzt den neuen Ioctl() "EXT4_IOC_SHUTDOWN" (1, 2). Userspace-Werkzeuge können dem Kernel darüber mitteilen, dass es beim Aushängen die noch im Schreibcache befindlichen Daten nicht wegschreiben muss, weil das Dateisystem ohnehin zerstört wird. Genau wie ein ähnlicher Funktionsaufruf von XFS ist das vornehmlich interessant, um die Handhabung von nur temporär benötigten Dateisystemen zu beschleunigen. Davon abgesehen gab es bei Ext4 vornehmlich Detailverbesserungen.

Auch beim beispielsweise bei Containern und Live-Medien eingesetzten Overlayfs gab es einige Änderungen. Durch eine von ihnen kann das Dateisystem jetzt mehrere Dateien gleichzeitig von einer der unteren in die oberste Schicht kopieren, was die Performance verbessert.

Vornehmlich Fehlerkorrekturen und kleinere Verbesserungen gab es auch beim Code der Dateisysteme Btrfs (1, 2), Ceph, F2FS, GFS2, NFS, NFSd, Orangefs, VFS (1, 2) und XFS.

Durch eine der Änderungen zeigt Linux in den per dmesg abrufbaren Log-Meldungen jetzt an, ob UEFI Secure Boot auf dem jeweiligen System aktiv ist. Das ist einigen Patches zu verdanken, die in ähnlicher Form schon länger in den Kerneln großer Linux-Distributionen stecken (1, 2, 3, 4). Letztere enthalten zumeist auch einige Änderungen, die zu Einschränkungen im Betrieb führen und beispielsweise das Laden unsignierter Kernel-Module unterbinden. Es gibt Bestrebungen, auch diese Patches in den offiziellen Linux-Kernel zu integrieren; noch ist aber noch ungewiss, ob das passieren wird.

Sicherheit steigern

Linux enthält jetzt eine Portierung des GCC-Plug-ins structleak. Dieses im Rahmen des Grsecurity-Projekts PAX entstandene Compiler-Plug-in initialisiert explizit Datenstrukturen, die sich der Kernel mit dem Userspace teilt. Das soll Informationslecks vermeiden, die Angreifern bei der Übernahme eines Systems dienlich sein könnten.

Unter den Änderungen am Security Layer befand sich auch eine bessere Unterstützung für TPM 2.0 (u.a. 1, 2). Außerdem unterstützt SELinux nun Label im Cgroupfs und beherrscht Kontext-Mounts von Tmpfs, Ramfs, Devpts in User Namespaces.

Die Anpassungen am Code für User Namspaces brachten Grundlagen für Änderungen, die unprivilegierte Anwender bald in die Lage versetzen sollen, innerhalb eines User Namespace ein Dateisystem einzuhängen.

Über /sys/kernel/security/lsm lässt sich nun auslesen, ob AppArmor, Capabilities, Yama, SELinux oder andere über Linux Security Modules (LSM) andockende Schutztechniken aktiv sind.

Auch beim Crypto-Subsystem gab es wieder einen ganzen Schwung von Änderungen. Darunter ist beispielsweise eine Implementation der AES-Verschlüsselung, die nicht so anfällig gegen Timing-Attacken ist wie AES-Code, der mit Lookup-Tabellen arbeitet.

Linux bringt jetzt eine Implementation des Hash- Algorithmus SipHash mit. Er soll die Sicherheit steigern und Wildwuchs beim Kernel-internen Verwenden von Hash-Algorithmen reduzieren, auf die der Kernel etwa zur Erzeugung von TCP-Sequenznummern, SYN Cookies, Port-Nummern oder einfachen Zufallszahlen zurückgreift. SipHash arbeitet dabei sogar schneller als MD5 oder SHA-1, die bislang häufig verwendet werden. Es arbeitet allerdings langsamer als Jenkins Hash (Jhash) – ein unsicherer, aber schneller Algorithmus, der in Bereichen zum Einsatz kommt, wo Sicherheit wenig oder keine Relevanz hat. Für solche Einsatzgebiete wurde die auf 32-Bit-Systeme schnellere, aber weniger Sicherheit bietende SipHash-Variante HalfSipHash1-3 eingebaut. Details zu den Einsatzfeldern der Algorithmen und ihren Vor- und Nachteilen liefern die verlinkten Commits und ein LWN.net-Artikel zu SipHash.

Beim Abrufen von Zufallszahlen via get_random_{int,long} erzeugt der Kernel diese nun mit Hilfe des Algorithmus, der auch zum Ausliefern eines zufälligen Datenstroms via /dev/urandom zum Einsatz kommt. Der Funktionsaufruf soll dadurch nicht nur schneller arbeiten, sondern auch bessere Zufallszahlen liefern.

Auch der neue Referenzzähler (Reference Counter) "refcount_t" soll Linux sicherer machen, denn er schützt gegen Refcounting Overflows, die sich Angreifer gelegentlich zunutze machen. Der neue Refcount-Typ soll bald "atomic_t" ersetzen.

Der i915-Treiber aktiviert bei allen modernen Intel-GPUs jetzt automatisch Framebuffer Compression (FBC), was die Leistungsaufnahme senken und somit die Laufzeit von Mobilgeräten steigern kann. Das Weiterleiten von Audio via DisplayPort funktioniert jetzt auch bei Bildschirmen, die der Grafikchip per Multi-Stream Transport (MST) anspricht (u. a. 1, 2, 3). Neben der GuC-Firmware kann der Treiber jetzt auch mit Firmware des Typs "HuC" umgehen, mit deren Hilfe sich Video-Encoding-Funktionen einiger Intel-GPUs nutzen lassen. Über eine neue Performance-Monitoring-Infrastruktur lässt sich die Arbeit von Hardware und Treibern besser überwachen, um Anwendungen oder den Treiber gezielt zu optimieren. Außerdem unterstützen die Grafik- und Audio-Treiber von Intel schon jetzt Prozessoren der Geminilake-Platform, die zur Atom-Klasse zählende CPU-Kerne enthalten und in einigen Monaten auf den Markt kommen sollen (1, 2, 3, 4).

Es gab eine Reihe von Detailänderungen an den AMD-Treibern, die die 3D-Leistung steigern und die Unterstützung von Stromsparfunktionen und Mehrschirmbetrieb verbessern. Von einigen dieser Umbauten profitiert auch der VMware-Grafiktreiber; andere greifen erst mit neuer AMD-Firmware, die aktuellen Versionen der Firmware-Sammlung linux-firmware enthält.

Polaris-Grafikchip

Außerdem unterstützt der AMD-Treiber nun eine weitere GPU der Polaris12-Baureihe, die auf den jüngst eingeführten Radeon-Rx-550-Grafikkarten zum Einsatz kommen.

Der Grafiktreiber für die GPUs der verschiedenen Raspberry-Pi-Modelle kann nun auch Bildschirm-Panels ansteuern, die via Display Serial Interface (DSI) angebunden werden.

Der Direct Rendering Manager (DRM), bei dem alle zuvor erwähnten Grafiktreiber andocken, bringt jetzt Tinydrm mit (u. a. 1, 2). Dabei handelt es sich um ein Framework, mit dem sich recht einfach Treiber für simple Bildschirm-Panel schreiben lassen sollen, die typischerweise über langsame Bussysteme wie I2C oder SPI angebunden sind. Zwei auf Tinydrm aufbauende Treiber bringt der Kernel bereits mit (1, 2, 3). Tinydrm richtet sich an die Maker Community; es stellt ähnliche Funktionen bereit, wie sie Fbtft geboten hat, das auf dem nicht mehr weiterentwickelten Framebuffer-Subsystem aufbaut.

Weitere Änderungen an den DRM-Grafiktreibern des Kernels nennt ein Git-Merge-Kommentar. Durch eine der vielen darin enthaltenen Änderungen unterstützt der Kernel nun den AST2500, der in einigen zur Fernwartung verwendeten BMCs (Baseboard Management Controller) steckt.

Linux 4.11 unterstützt über 28.000 Geräte oder Geräteklassen; das sind knapp 400 mehr als sein Vorgänger. Das geht aus den Datenbanken der Linux Kernel Driver DataBase (LKDDb) hervor, laut denen die neue Kernel-Version über 170 PCI/PCIe- und USB-Geräte mehr unterstützt als die davor.

Zur erstmals unterstützten Hardware gehören die HD-Audio-Codecs ALC299 und ALC1220 von Realtek; Letzterer steckt auf einigen der Mainboards für die neuesten Prozessorserien von AMD (Ryzen) und Intel (Kaby Lake/Core-i 7xxx). Ganz neu dabei sind auch Treiber für die zweite Generation der Wacom Intuos Pro Pen und Touch Tablets, Silead Touchscreens sowie das Lenovo Thinkpad X1 Tablet Dock.

Unter den neuen Netzwerktreibern ist einer für 2.5/5-Gigabit-Ethernet-Chips von AQtion (u. a. 1, 2, 3). Außerdem unterstützt Linux nun auch die 10/40/100-Gbit-Ethernet-Chips NFP4000 und NFP6000 von Netronome (1, 2). Neu dabei ist auch ein RoCE-Treiber für die Broadcom-HCAs NetXtreme-E 10/25/40/50G RoCE HCAs.

Der Sound-Treiber bcm2835-audio floss in den Staging-Bereich ein, der Code mit bekannten Qualitätsmängeln aufnimmt. Der Treiber unterstützt die HDMI-Audio-Funktion der System-on-a-Chip (SoC), die auf den verschiedenen Raspberry-Pi-Modellen stecken (1, 2). Auch deren Kamera-Interface unterstützt Linux jetzt, denn es bringt einen dafür zuständige V4L2-Treiber mit (u. a. 1, 2). Auch er hat größere Defizite und liegt daher ebenfalls im Staging-Bereich. Einige dort liegenden Treiber für vermutlich nicht mehr eingesetzte ISDN-Karten mussten weichen.

Details zu weitere Neuerungen bei Treibern und den sie umgebenden Infrastruktur finden sich in den Merge-Commit-Kommentaren der Subsysteme Char, Driver Core, EDAC, HID, Hwmon, Input, LEDs, Media, MFD, Platform, RDMA (1, 2), Sound, Staging, TTY, USB und Watchdog.

Manche per PCI Express (PCIe) angebundene Hardware kann mit dem neuen Kernel tiefer schlafen, was die Leistungsaufnahme reduziert und so die Akkulaufzeit mobiler Geräte steigert. Dieser Vorteil ist dem Support für "ASPM L1 Substates" zu verdanken, der bei PCIe 3.1 spezifiziert wurde; manche Chips implementieren die Stromspartechnik bereits.

Linux 4.11 beherrscht Intels "Turbo Boost Max Technology 3.0" auch bei Xeon-Prozessoren der Broadwell-Generation, bei denen sich der Prozessor nicht selbst per HWP (Hardware-managed P-states) um das Hoch- und Heruntertakten kümmert, weil diese Funktion im BIOS-Setup deaktiviert wurde. Für andere Systeme ist das nicht relevant, denn in der Regel ist HWP standardmäßig aktiv; dort reicht daher die bei Linux 4.10 eingeführte Unterstützung für Intels neueste Turbo-Technik, durch die ein Prozessorkern höher takten kann als die anderen.

Beispielausgabe von "perf ftrace" Bild: Commit auf git.kernel.org

An Performance-Monitoring mit der Werkzeugsammlung perf interessierte Anwender sollten einen Blick in die wichtigsten Änderungen am Perf-Subsystem werfen, denn dort gab es wieder Dutzende von Verbesserungen. Darunter beispielsweise Unterstützung für Intels neue Prozessorgeneration Kaby Lake. Außerdem haben die Entwickler den Perf-Support für AMD-CPUs der Zen-Familie verbessert, zu denen der jüngst eingeführte Ryzen-Prozessor zählt. Zu den im Rahmen des Linux-Kernels entwickelten Perf-Werkzeugen stieß perf ftrace; dabei handelt es sich um ein derzeit eher rudimentäres Werkzeug zur Ablaufverfolgung, mit dem sich einige Funktionen der Kernel-eigenen Function Tracers (Ftrace) jetzt auch via Perf nutzen lassen.

Das dem Kernel beiliegende Analyseprogramm turbostat wurde auf den aktuellen Stand gehoben. Das Werkzeug zeigt an, wie lange moderne Intel-Prozessoren und ihre Kerne in welcher Betriebsart verbringen; mit dem Tool kann man so feststellen, mit welcher Taktfrequenz die verschiedenen Teile des Prozessors laufen oder wie lange welche Baugruppe wie tief schläft. Durch die Umbauten ist das Programm mächtiger als zuvor, unterstützt mehr Prozessoren und kennt eine Reihe neuer Kommandozeilenoptionen.

Auch analyze_suspend.py wurde auf eine deutlich neuere Version gehoben (1, 2, 3, 4). Dieses im Rahmen des Kernels entwickelte Analyseprogramm untersucht den Wechsel in und aus dem Bereitschaftsmodus. Damit lassen sich beispielsweise Treiber aufspüren, die Suspend oder Resume verlangsamen.

Es gab auch Anpassung, durch die man das Verhalten des zum Hoch- und Heruntertakten moderner Intel-Prozessoren zuständigen Treibers intel-pstate via Sysfs beeinflussen lässt. Außerdem stieß ein Userspace-Werkzeug zum Kernel, das die Arbeit des Treibers analysiert.

Bei Angabe des Boot-Parameters vgacon.scrollback_persistent=1 kann man auf einer Textkonsole (Virtual Terminal/VT) nach oben hinausgelaufenen Text auch dann noch per "Shift-BildHoch" abrufen, nachdem man vorübergehend auf eine andere Konsole gewechselt war (1, 2). Bislang gelang das nur bei angeschalteter Kernel-Konfigurationsoption VGACON_SOFT_SCROLLBACK_PERSISTENT, was bei manchen Distributionskerneln nicht der Fall war. Diese Option wurde durch VGACON_SOFT_SCROLLBACK_PERSISTENT_ENABLE_BY_DEFAULT ersetzt; wenn sie gesetzt ist, kann man sich die Angabe des erwähnten Boot-Parameters sparen.

Bei LZ4 Fast lässt sich das Verhältnis zwischen Kompressionsaufwand und Geschwindigkeit feiner festlegen. Bild: Commit bei git.kernel.org

Die Kernel-Entwickler haben den schon länger nicht mehr aktualisierten LZ4-Code auf den Stand des im Herbst freigegebenen LZ4 1.7.3 gehoben. Das beseitigt eine Reihe von Fehlern und verspricht Performance-Verbesserungen, wenn Kernel-Code mit LZ4 packt oder entpackt, wie es beispielsweise beim Einsatz von Pstore oder Squashfs der Fall sein kann. Außerdem unterstützt der Kernel dadurch jetzt den Kompressionsalgorithmus "LZ4 fast", bei dem sich das Verhältnis zwischen Aufwand und Geschwindigkeit beim Komprimieren feiner festlegen lässt. Dem Update waren einige bei LWN.net erläuterte Diskussionen vorausgegangen: Die Kernel-Entwickler konnten nicht einfach auf eine neue Version wechseln, weil sie Änderungen am Code vorgenommen hatten, die nicht an die LZ4-Entwickler zurückgeflossen waren; zugleich hatten die Kernel-Entwickler aber auch vergessen, einige zwischenzeitlich in LZ4 vorgenommene Sicherheitskorrekturen in Linux zu integrieren.

Die Linux-Quellen sollten jetzt etwas flotter kompilieren. Das ist Umbauten an den Include-Dateien des Prozess-Scheduler und deren Einbindung zu verdanken, die zahlreiche Dateien betreffen.

Die Umbauten am KVM-Code enthalten kleinere Performance-Optimierungen (1, 2).

Die verschiedenen Betriebsmodi von Xen. Bild: wiki.xen.org; Lars Kurth, CC-BY-SA-3.0

Unter den Patches für Xen waren Änderungen, durch die Linux jetzt als PVHv2-Gast arbeiten kann (u. a. 1, 2). Dabei handelt es sich um eine grundlegend überarbeitete Fassung des Virtualisierungsmodus, der weitgehend Paravirtualisierung nutzt, aber für Performance-kritische Funktionen wie die Speicherverwaltung die Virtualisierungsfunktionen des Prozessors zur Hilfe nimmt. Details zu dieser manchmal auch HVMLite genannten Betriebsart erläutert das Xen-Wiki. Ferner gab es Änderungen am Xenbus-Treiber, die die Performance verbessern sollen.

Linux 4.11 unterstützt den Banana Pi M64. Bild: banana-pi.org

Der ARM-Code unterstützt nun den Einplatinencomputer Banana Pi M64, auf dem ein Allwinner A64 steckt. Das ist aber nur eine von zahlreichen Änderungen, die es am Code für ARM (Core, SOC, SOC-Defconfig, SOC-Driver, SOC-DT [1, 2]) und ARM64 (Core, SOC, SOC-DT) gab. Allerlei Änderungen gab es auch am Code zur Unterstützung von M68K, MIPS, OpenRISC, PowerPC (1, 2), S390 (1, 2) und SPARC; beim Code für die vielen anderen von Linux unterstützten Prozessor-Architekturen gab es vorwiegend Detailänderungen.

Details zu weiteren Neuerungen an der Infrastruktur finden sich in den Merge-Kommentaren der Subsysteme ACPI, Cgroup, Dokumentation, Iommu, Locking, PCI, Printk, Power-Management (1, 2), Virtio/Vhost, Thermal Management, Scheduler, Timer und Tracing.

Kernel-
Version
Anzahl
Dateien¹
Zeilen
Quelltext
(Ohne Doku)²
Entwick-
lungs-
zeitraum
Anzahl
Commits³
Diffstat⁴
Linux 4.4 52221 20.862.229
(19.243.827)
70 Tage 14.082 10.604 files changed,
713.754 insertions(+),
470.774 deletions(-)
Linux 4.5 52916 21.154.659
(19.489.725)
63 Tage 13.173 11.590 files changed,
1.146.355 insertions(+),
854.286 deletions(-)
Linux 4.6 53660 21.422.808
(19.724.413)
63 Tage 14.618 10.250 files changed,
606.023 insertions(+),
337.875 deletions(-)
Linux 4.7 54400 21.720.955
(19.971.725)
70 Tage 13.433 9909 files changed,
575.816 insertions(+),
277.305 deletions(-)
Linux 4.8 55503 22.071.048
(20.266.168)
70 Tage 14.552 11.483 files changed,
662.558 insertions(+),
314.177 deletions(-)
Linux 4.9 56223 22.348.356
(20.520.460)
70 Tage 17.392 11.416 files changed,
713.497 insertions(+),
436.209 deletions(-)
Linux 4.10 57202
22.839.659
(20.864.595)
70 Tage 14.249 11.913 files changed,
806.420 insertions(+),
312.218 deletions(-)
Linux 4.11 57994 23.137.402
(21.132.076)
70 Tage 13.891 12.528 files changed,
550.108 insertions(+),
252.364 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
⁴ git diff --shortstat vx.(y-1)..vx.(y)

Mit der Freigabe von Linux 4.11 beginnt jetzt die zweiwöchige Phase, in der Linus Torvalds das Gros der Änderungen für den Nachfolger aufnimmt. Dieses "Merge Window" schließt der Linux-Erfinder typischerweise nach zwei Wochen mit der Veröffentlichung einer ersten Vorabversion ab. Sie läutet zugleich die Stabilisierungsphase ein. Derzeit ist diese meist acht Wochen lang, daher erscheint Linux 4.12 wahrscheinlich am 10. Juli; es waren aber auch häufiger schon nur sieben Wochen, daher könnte es bereits am 3. Juli so weit sein.

(thl)

Den neuen Linux-Kernel herunterladen und einrichten

Die neue Linux-Version steht wie gewohnt über Kernel.org zum Download bereit. Hinweise zur Einrichtung eines eigenen Kernels finden Sie im Artikel "Linux-Kernel maßgeschneidert". 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 das neue Linux in den nächsten Wochen über die Systemaktualisierung erhalten. Bei OpenSuse Leap, Ubuntu und vielen anderen klassisch gewarteten Distributionen wird das nicht passieren, denn dort macht der Kernel normalerweise nur beim Wechsel auf eine neue Ausgabe der Distribution einen Versionssprung.

Versionshistorie dieses Artikels

Dieser Artikel wird zwischen Freigabe der ersten Vorabversion und Fertigstellung von Linux 4.11 mehrfach erweitert, um schrittweise alle wichtigen Änderungen der neuen Kernel-Version zu erläutern. Einmal publizierte Absätze werden indes nur verändert, wenn triftige Gründe es erfordern.

74 Kommentare

Anzeige
Anzeige