Die Kernelentwicklung lief trotz Corona weiter, als wäre nichts passiert. Die meisten Linux-Entwickler arbeiten ohnehin Remote, entsprechend erschien der Kernel 5.7 pünktlich am vergangenen Wochenende. Größere Vorkommnisse: Keine.
Als eine der ersten Aktionen im Release-Zeitraum warf Greg Kroah-Hartman den Exfat-Staging-Treiber aus dem Kernel. Immerhin gebe es nun im VFS-Tree einen „echten“ Exfat-Treiber. Von Ard Biesheuvel kamen bereits Ende Februar EFI-Updates für den 5.7er-Kernel. Ein Linux/UEFI-Boot-Protokoll im Kernel 5.7 bringt zum Beispiel eine generische Lademethode mit, um “initrd” zu laden. Ebenfalls recht früh im Release-Zyklus landete Code für Mediateks Wifi-Chip MT7615, der unter anderem die Standards IEEE 802.11ac und IEEE 802.11 a/b/g/n abdeckt.
Netzwerk- und KVM-Updates
Updates erhielt auch die Architektur von IBMs Großrechner-Familie S/390. Diese betreffen unter anderem KVM und erlauben den Einsatz geschützter virtueller Maschinen (Protected VMs, PVM). Das bedeutet, dass KVM nicht auf den Speicher und die Register der Gastsysteme zugreifen darf. Vielmehr bietet ein so genannten Ultravisor ein API an, um diese Maschinen zu verwalten. Dabei wechseln die PVMs erst nach einem Standard-Bootprozess in den geschützten Modus. Sind sie gerade nicht im Einsatz, liegen sie verschlüsselt auf der Festplatte. Neustarts erfordern einen temporären Wechsel in den ungeschützten Modus.
Im Netzwerkbereich soll das neue VLAN-API mit dem alten gleichziehen. Daher haben die Entwickler ein Patchset eingebaut, das Tunnel Mapping ergänzt, mitsamt Statistiken. Neben kleinen Updates an Netfilter und Bluetooth warten Änderungen an Multipath-TCP: Ein Patch erlaubt es, mehr als einen TCP-Subflow in einer Multipath-TCP-Verbindung zu etablieren. Neue Subflows bindet die “MP_JOIN”-Option im Zuge des Drei-Wege-Handshakes ein.
Aktualisierte Grafik- und FS-Treiber
Der “i915”-Treiber unterstützt nun Intels Tigerlake-Architektur. Außerdem bringen “i915” und “amdgpu” ersten Support für OLED-Backlights mit. Der Code existiere lauf Dave Airlie bereits länger, laufe aber erst jetzt auf echter Hardware. Der “vmgfx”-Treiber bringt neuerdings Userspace-Support für OpenGL 4 mit.
Auch bei den Dateisystemen gab es wieder Aktualisierungen. Btrfs profitiert laut David Sterba von einer Reihe an Verbesserungen im Kernbereich, der den Code einfacher und sauberer mache. Zudem bereiten die Entwickler das Feld für Zoned-Device-Support. Das Flash-Dateisystem F2SF unterstützt jetzt Zstd und verwendet LZ4 als Standardkompression. Die XFS-Entwickler arbeiten an der Metadaten-Validierung und an der Basis für künftige Online-Reparaturen, bei denen Reparaturen also stattfinden, während XFS im Einsatz ist.
Microsofts GPU-Treiber
Etwas Aufregung löste ein Vorschlag von Microsoft zu einem virtuellen GPU-Treiber (vGPU) namens Dxgkrnl aus, den Kernel-Entwickler Sasha Levin am Rande der Build-Konferenz im Mai auf der Kernel-Mailingliste ankündigte. Levin betreut unter anderem das Hyper-V-Subsystem. Der Treiber steckt in WSL 2, dem Windows Subsystem for Linux 2, soll nun aber am liebsten im offiziellen Kernel landen. Er erlaubt es, die Render- und Rechenkapazitäten einer oder mehrerer GPUs des Hostsystems an WSL2 durchzureichen. Aus dem Linux-Gastsystem heraus greifen dann die Libdirectml, Libd3d12 oder Libdxcore direkt auf die Windows-GPU zu. Wesentliches Ziel ist es, Windows-Nutzern zu erlauben, Machine-Learning-Jobs aus WSL2 heraus zu starten und auf der Windows-GPU zu rechnen.
In einem Blogpost konstatierte Dave Airlie, dass am Ende zwei proprietäre Programme, eines im Linux-Gast, eines im Windows-Kernel, über ein geschlossenes Protokoll miteinander reden. Diese reine WSL2-Pipeline sei damit für das restliche Linux-Ökosystem ohne Mehrwert. Er könne sich grundsätzlich vorstellen, den Code in den Hyperv-Bereich des Kernels zu schieben, nicht aber nach “drivers/gpu”. Er möchte in diesem Fall aber einen groben Plan dafür sehen, wie Microsoft die Presentation-Fähigkeiten der GPUs später nachreichen möchte. Auch Daniel Vetter, ebenfalls verantwortlich für den DRM-Bereich, zeigte sich zwar grundsätzlich erfreut über den Schritt von Microsoft, sah aber noch Redebedarf. Denn die Aufnahme in das “drivers/gpu” -Subsystem verlange laut den Freedesktop-Richtlinien nach einem offenen Userspace. Aufgrund der Compute- und Machine-Learning-Fähigkeiten der GPUs schlug Daniel Vetter vor, den Treiber als Accelerator-Treiber zu verwenden. So würde er dann in “drivers/accel” landen. Zugleich stellte er die Frage, ob Microsoft nun plötzlich plane, DirectX 12 auf Linux zu portieren.
Kein Direct X 12 auf Linux
Levins Antwort: Das sei nicht der Fall. Er und sein Team wollen aktuell lediglich herauszufinden, ob der genannte Treiber überhaupt den DRM-Bereich von Linux berühre, gerade mit Rücksicht auf die Grafiknutzung der GPUs. Schließlich werde auf der Linux-Seite nichts gerendert, sondern die Daten würden lediglich durchgeschoben. Längerfristig wolle Microsoft OpenCL 1.2 und OpenGL 3.3 auf Windows-Geräte mit DirectX 12 bringen. An der Umsetzung arbeitet unter anderem Collabora.
Steve Pronovost, der bei Microsoft in der Entwicklung arbeitet, brachte noch etwas mehr Klarheit. Die im Zuge der Build-Konferenz ebenfalls angekündigte Möglichkeit, grafische Linux-Anwendungen auszuführen, soll demnach wohl über FreeRDP laufen. Auf der Linux-Seite soll ein Wayland-Compositor zum Einsatz kommen und die Desktop-Komponenten über den RDP-RAIL-Channel an Windows weiterreichen. Um das umzusetzen, will Microsoft sowohl mit dem Wayland-Projekt als auch mit FreeRDP zusammenarbeiten und den dabei entwickelten Code veröffentlichen und dokumentieren. Falls Microsoft DirectX 12 auf Linux portieren wollen würde, dann wahrscheinlich auf Basis der vorhandenen DRI/DRM-Infrastruktur.
Zu viele Makros?
Google-Mitarbeiter KP Singh brachte ebenfalls kritisch beäugten Code ein, der BPF-Programme mit LSM-Hooks (Linux Security Module) verbinden soll. Das eBPF-Programm “BPF_PROG_TYPE_LSM” lasse sich mit LSM-Hooks koppeln und könne einheitliche und dynamische Audit- und MAC-Richtlinien im Kernel ermöglichen. Der Hintergrund: Laut Singh versuche Google im Rahmen des Cilium-Projekts, Bedrohungen in Echtzeit zu erkennen. Dazu analysiert es Sicherheitsdaten von Laufzeitumgebungen. Dies geschehe aktuell über ein angepasstes Kernelmodul, wäre aber laut Singh im Standardkernel besser aufgehoben. Doch die Zugriffskontrolle (LSM) sei im Kernel von der Telemetrie-Infrastruktur getrennt, daher der über BPF realisierte Änderungswunsch.
Beobachter auf der Mailingliste, darunter der Entwickler Casey Schaufler, monierten aber den exzessiven Einsatz von Makros und stellten die Frage, ob es sinnvoll sei, die Komplexität der LSM-Infrastruktur unnötig weiter zu steigern. Security-Experte Kees Cook widersprach: Für ihn vereinfacht der Einsatz von Makros den Code. Er sehe darin kein schädliches Verhalten, da BPF das LSM-Backend permanent überwache. Wer die neue Kernelversion testen möchte, findet diese wie gewohnt auf Kernel.org oder auf Github.
