© liligraphie, 123RF

Linus trennt sich nach 15 Jahren von seiner Intel-Maschine, ein von Microsoft angebotener Treiber stiftet Verwirrung, und es gibt Beef zwischen BPF- und LSM-Entwicklern.

Die größte Aufregung im Release-Zyklus von Linux 5.7 verursachte für Linus Torvalds wohl der Wechsel auf einen AMD-Rechner in der vorletzten Release-Woche. Nach 15 Jahren Intel Inside treibt nun ein Threadripper 3970x den Hauptrechner des Kernel-Chefs an. Seine »allmodconfig«-Testbuilds würden nun drei Mal schneller laufen, erklärte er. Ob sich der Umstieg noch in anderen Bereichen auf die Kernel-Entwicklung auswirkt, muss die Zukunft zeigen [1]. Trotz Corona verlief die Kernel-Entwicklung dabei weiter, als wäre nichts. Die meisten Linux-Entwickler arbeiten ohnehin remote – entsprechend erschien der Kernel 5.7 pünktlich [2].

ExFAT- und EFI-Updates

Als eine der ersten Aktionen im aktuellen Release-Zeitraum warf Greg Kroah-Hartman den ExFAT-Staging-Treiber aus dem Kernel, da es im VFS-Tree nun einen “echten” ExFAT-Treiber gibt.

Von Ard Biesheuvel kamen bereits Ende Februar EFI-Updates für den 5.7er-Kernel. Für die eher umfangreichen Änderungen gab Biesheuvel zwei Gründe an: Einerseits bereite man das EFI-Subsystem auf den RISC-V-Support vor, andererseits akzeptiere das Grub-Projekt mittlerweile Beiträge von den Distributionen in Sachen Secure und Measured Boot. Als Reaktion auf die Änderungen, und um den eigentlich nicht betroffenen Architekturen Arbeit zu ersparen, landet nun ein generisches Linux/UEFI-Boot-Protokoll im Kernel 5.7. Das bringt zum Beispiel eine Lademethode mit, um die Initrd zu laden.

Ebenfalls recht früh im Release-Zyklus trudelte Kernel-Code für Mediateks Wi-Fi-Chip MT7615 ein, der unter anderem die Standards IEEE 802.11ac und IEEE 802.11a/b/g/n erfüllt. Der Treiber hatte es laut Entwickler Kalle Valo nicht mehr in den Kernel 5.6 geschafft.

Netzwerk- und KVM-Updates

Software-Updates erhielt auch die Architektur von IBMs Großrechner-Familie S/390. Sie 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 sogenannter Ultravisor eine 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 jedoch 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 mitsamt Statistiken ergänzt. Neben kleinen Updates an Netfilter und Bluetooth warten Änderungen an Multipath-TCP: Das darf neuerdings dank eines Patches mehr als einen TCP-Subflow in einer Multipath-TCP-Verbindung etablieren. Neue Subflows bindet die »MP_JOIN«-Option im Zuge des Drei-Wege-Handshakes ein.

Grafik-Updates

Ganz ohne Witz lieferte Dave Airlie, der den offenen Grafik-Stack in Linux betreut, am ersten April die wesentlichen Patches für das Grafiksystem ab. Der Treiber »i915« unterstützt nun Intels “Tigerlake”-Architektur. Außerdem bringen »i915« und »amdgpu« ersten Support für OLED-Backlights mit. Der Code existiere schon länger, laufe aber erst jetzt auf echter Hardware, ließ Airlie wissen. Zugleich bringt der Treiber »vmgfx« nun Userspace-Support für OpenGL 4 mit.

Auch bei den Dateisystemen gab es wieder Aktualisierungen. Btrfs profitiert laut David Sterba von diversen Verbesserungen im Kernbereich, die den Code einfacher und sauberer machen. Zudem bereiten die Entwickler das Feld für Zoned-Device-Support. Das Flash-Dateisystem F2SF unterstützt jetzt Facebooks Zstd-Komponenten und verwendet LZ4 als Standardkompression. Die XFS-Entwickler arbeiten an der Metadatenvalidierung und an der Basis für künftige Online-Reparaturen, bei denen Reparaturen stattfinden, während XFS im Einsatz ist.

GPU-Treiber von Microsoft

Etwas Aufregung löste Microsofts Bitte aus, einen virtuellen GPU-Treiber (vGPU) namens Dxgkrnl [3] in das »drivers/gpu/«-Subsystem des Kernels zu integrieren. Einen ersten Entwurf kündigte der Kernel-Entwickler Sasha Levin am Rande der Build-Konferenz im Mai auf der Kernel-Mailing-Liste [4] an. Levin betreut unter anderem das Hyper-V-Subsystem.

Der Treiber steckt bereits in WSL 2, dem Windows Subsystem for Linux 2, soll nun aber am liebsten im offiziellen Kernel landen. Er erlaubt es, eine oder mehrere GPUs des Host-Systems an WSL2 durchzureichen. Dabei schleift der Treiber (bislang) nur die Render- und Rechenkapazitäten der GPUs durch, nicht aber die Anzeigefähigkeit (Presentation). Aus dem Linux-Gastsystem heraus dürfen dann die Bibliotheken Libdirectml, Libd3d12 oder Libdxcore direkt auf die Windows-GPU zugreifen (Abbildung 1). Das Ziel der Übung besteht im Wesentlichen darin, Machine-Learning-Jobs aus WSL2 heraus zu starten und auf der Windows-GPU zu rechnen.

Abbildung 1: Microsoft möchte es Nutzern des WSL2 ermöglichen, Machine-Learning-Jobs auf der GPU des Host zu starten. Quelle: https://devblogs.microsoft.com

Einspruch

Während Greg Kroah-Hartman den Treiber grundsätzlich begrüßte und nur ein paar kleine Fehler im Code anmahnte, äußerte sich Dave Airlie kritischer über die Aufnahme in “sein” »drivers/gpu/«-Subsystem. In einem Blogpost [5] konstatierte er, dass Microsofts Treiber nur mit WSL2 funktioniere. Es sei also nicht so, dass DirectX nun auf Linux laufe. Vielmehr kommunizieren am Ende laut Airlie zwei proprietäre Programme über ein geschlossenes Protokoll miteinander – eines im Linux-Gast, eines im Windows-Kernel. Diese reine WSL2-Pipeline sei damit für das restliche Linux-Ökosystem ohne Mehrwert.

Airlie könne sich grundsätzlich vorstellen, den Code in den Hyper-V-Bereich des Kernels zu schieben, nicht aber nach »drivers/gpu/«. Allerdings wolle er in diesem Fall zuvor einen groben Plan dafür sehen, wie Microsoft später die Presentation-Fähigkeiten der GPUs nachrüsten möchte: Dieser Punkt könnte beispielsweise eine Interaktion mit »dma-bufs« und »dma-fences« erfordern, womit der Code wieder in seinem Bereich lande.

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. Die Aufnahme in das »drivers/gpu/«-Subsystem verlange laut den Freedesktop.org-Richtlinien [6] nach einem offenen Userspace, den Microsoft aber nicht anbiete. Zudem erfinde der Treiber das Rad an bestimmten Stellen neu. Weiterhin fragte er, ob Microsoft nun plötzlich plane, DirectX 12 auf Linux zu portieren, und ob hier eine neue Variante der Divide-and-Conquer-Strategie im Gange sei?

Das verneinte Sasha Levin natürlich. Er persönlich bedauere, dass der Userspace-Teil nicht quelloffen sei und wünschte sich, er könne daran etwas ändern. Microsoft wolle DirectX 12 nicht in die Linux-Welt bringen, zumal es ja bereits einen DX-12-Gallium-Treiber gebe. Vielmehr gehe es um einen einzigen Use Case: Entwicklern, die WSL2 für Machine Learning verwenden wollen, den Zugriff auf die Windows-GPUs zu erlauben.

Sein Team und er seien keine Experten im Linux-DRM-Bereich. Man versuche aktuell lediglich herauszufinden, ob der 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 [7].

Zumindest für die Compute- und Machine-Learning-Fähigkeiten der GPUs schlug Daniel Vetter schließlich vor, den Treiber als Accelerator-Treiber zu verwenden. So würde er dann in »drivers/accel/« landen.

Linux-GUI-Apps unter Windows

Am Ende schaffte Steve Pronovost, der bei Microsoft in der Entwicklung arbeitet, noch ein wenig mehr Klarheit bezüglich der Microsoft-Pläne zu Linux-GUI-Anwendungen. Die im Zuge der Build-Konferenz angekündigte Möglichkeit, grafische Linux-Anwendungen auszuführen, will Microsoft demnach wohl über FreeRDP realisieren. Auf der Linux-Seite soll ein Wayland-Compositor zum Einsatz kommen, der die Desktop-Komponenten über den RDP-RAIL-Channel an Windows weiterreicht. Um das umzusetzen, will Microsoft sowohl mit dem Wayland-Projekt als auch mit FreeRDP zusammenarbeiten und den dabei entwickelten Code veröffentlichen und dokumentieren.

Tatsächlich hatte Microsoft wohl mit dem Gedanken gespielt, DirectX auf Linux zu portieren, ganz ohne Windows-Abhängigkeiten. So jedenfalls lässt sich eine etwas kryptische Aussage von Pronovost deuten: “We have consider (!) the possibility of bringing DX to Linux with no Windows cord attached. I’m not ready to discuss this at this time.” In diesem hypothetischen Fall würde DirectX dann aber laut Pronovost auf der DRI/DRM-Infrastruktur von Linux aufsetzen.

Zu viele Makros?

Nicht nur Microsofts Vorschlag sorgte für Diskussionen. Auch Google-Mitarbeiter K.P. Singh brachte kritisch beäugten Code ein, der BPF-Programme mit LSM-Hooks (Linux Security Module) verbinden soll [8]. 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 versucht Google im Rahmen des Projekts Cilium, Bedrohungen in Echtzeit zu erkennen, und analysiert dazu Sicherheitsdaten von Laufzeitumgebungen. Dies geschieht aktuell über ein angepasstes Kernel-Modul, wäre aber laut Singh im Standard-Kernel besser aufgehoben. Doch die Zugriffskontrolle (LSM) sei im Kernel von der Telemetrie-Infrastruktur getrennt – daher der Wunsch nach einer über eBPF realisierten Änderung.

Beobachter auf der Mailing-Liste, darunter der Entwickler Casey Schaufler, monierten aber den exzessiven Einsatz von Makros [9] 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 sieht darin kein schädliches Verhalten, da eBPF das LSM-Backend permanent überwache.

LSM versus eBPF

Eine weitere Kontroverse mit Bezug auf eBPF entspann sich abseits des Hauptgeschehens auf der Kernel-Summit-Liste [10]. Sie verwickelte Entwickler der eBPF-basierten KRSI (Kernel Runtime Security Instrumentation) auf der einen und des Linux Security Module auf der anderen Seite.

Als Entwickler Kees Cook seine Diskussionsthemen rund um Seccomp für den Summit ankündigte und nebenbei anmerkte, er wolle den BPF-Dialekt von Seccomp nicht auf eBPF erweitern, platzte eBPF-Entwickler Alexei Starowoitow offenbar der Kragen. Etwas rüde warf er Cook vor, dass Seccomp schon jetzt extrem langsam sei und im Produktionseinsatz praktisch unbenutzbar. Er kritisierte auch, dass Cook lieber auf Syscall-Bitmasken setze, als auf eBPF, um Seccomp zu beschleunigen. Dafür neuen Code zu integrieren, führe zu mehr Bugs und einer größeren Security-Angriffsfläche.

Cooks Antwort kam postwendend: Syscall-Bitmasken würden wesentlich schneller arbeiten als selbst einzeilige BPF-basierte Seccomp-Filter. Was die Sicherheit angehe, folge er ebenfalls dem Prinzip, Software einfach zu halten, um Bugs zu vermeiden. Historisch sei Seccomp wesentlich sicherer als eBPF. Er würde es gern weiterhin vor den regelmäßigen Sicherheitslücken von eBPF schützen. Und dass Seccomp im Produktiveinsatz unbenutzbar sei, sei Starowoitows Meinung, decke sich aber nicht mit dem Umstand, dass es in vielen Rechenzentren zum Einsatz komme.

Wie es scheint, besteht also auf beiden Seiten noch Redebedarf, den ja womöglich der geplante Kernel-Summit behebt. Wer bis dahin die neue Kernel-Version testen möchte, findet diese wie gewohnt auf Kernel.org oder auf Github [11].