Seite 2: Kernel-Funktionen direkt in eBPF nutzen

Inhaltsverzeichnis

Der extended Berkeley Packet Filter (eBPF) erlaubt es, Programme aus dem Userspace zu laden und im Kernel-Context ablaufen zu lassen, ohne hierfür den Kernel-Quellcode zu ändern oder Kernel-Module zu laden. Damit das Sinn ergibt, müssen die eBPF-Programme beziehungsweise die eBPF-Virtual-Machine mit dem Kernel interagieren. Bislang wurde der Zugang zur Funktion im Kernel – aus gutem Grund – restriktiv gehalten. Der Kernel bringt nun eine Neuerung: eBPF-Programme können zuvor festgelegte Kernel-Funktionen direkt aufrufen. Dabei operiert der neue Mechanismus am Kernel-ABI vorbei.

Ausgangspunkt für diese Lockerung war die TCP-Congestion-Control in eBPF von Martin KaFai Lau. Die Congestion-Control soll Überlast auf dem Netzwerk verhindern. Hierzu kommen ausgefeilte Algorithmen zum Einsatz, die ursprünglich im Kernel-Code beheimatet sind. Lau führt diese teilweise in die eBPF mit dem Ziel kürzerer Durchlaufzeiten (turn-around) und schlankerer Kernel ein. Zudem sind neue TCP-Congestion-Control-Algorithmen aus dem Userspace einfacher in die eBPF zu schieben und zu testen als über modifizierten Kernel-Code.

Dem Unterfangen standen Beschränkungen der eBPF im Weg, die unterbanden, benötigte Kernel-Funktionen zu verwenden. Daher reimplementierte die eBPF-Variante der Congestion-Control viele Funktionen erneut. Es entstand somit eine "Parallelwelt" in und für eBPF zur bereits im Kernel vorhandenen Funktion. Um diese Redundanz aufzulösen, schuf Lau einen neuen Mechanismus, der es eBPF-Programmen gestattet, solche Kernel-Funktionen zu verwenden.

In eBPF werden Kernel-Funktionen über ein schlichtes extern-Statement eingebunden. Damit das nicht in einen "Freibrief" für alle eBPF-Programme ausartet, muss auf der Kernel-Seite die jeweilige Kernel-Funktion für die betreffenden eBPF-Programmtypen freigegeben werden. Das geschieht über die zum jeweiligen eBPF-Programmtyp gehörigen bpf_verifier_ops-Struktur. Über den Member check_kfunc_call dieser Struktur wird ein Zeiger auf eine Funktion hinterlegt, die als "Prüfstelle" und Berechtigungsfreigabe dient. Wenn ein eBPF-Programm eine Kernel-Funktion aufrufen will, startet der eBPF-Verifier die hinterlegte "Prüffunktion". In dieser Prüffunktion ist der Entwickler frei, eigene Regeln zur Berechtigungsprüfung zu hinterlegen. Die Funktion gibt über einen booleschen Wert zurück, ob das eBPF-Programm die jeweilige Kernel-Funktion nutzen darf.

eBPF als Risiko?

Aktuell nutzen diesen Mechanismus nur Congestion-Control-Programme für die Kernel-Funktion tcp_slow_start(). Zukünftig dürften das jedoch mehr werden, denn ist ein Feature vorhanden, finden sich dafür auch Anwendungen. Öffnet sich hier die Büchse der Pandora?

Der Mechanismus ist aus zwei Gründen mit Vorsicht anzuwenden. Zunächst ist die extern-Deklaration im eBPF-Programm problematisch. Ein solides Prototyping ist ausgehebelt. Ändert sich die Signatur einer Kernel-Funktion und wird das eBPF-Programm nicht nachgezogen, wird die Kernel-Funktion mit falschen Parametern aufgerufen. Die Folgen sind logische Fehler bis hin zur Kernel Panic. Ob das der jeweilige C-Kompiler im Vorfeld bemängelt, bleibt vom Einzelfall abhängig. Sicherer wäre hier ein klarer Weg über die Kernel-ABI.

Der zweite Grund sind Sicherheitsbedenken. eBPF-Programme prüft das eBPF-System zwar. Das neue und wesentlich offenere Freigabesystem für Kernel-Funktionen stellt das eBPF-System vor neue Herausforderungen. Bislang war starr geregelt, was ein eBPF nutzen darf. Jetzt kann theoretisch das Kernel-Repertoire nahezu beliebig geöffnet werden. Die Frage ist, ob das eBPF-System seiner Prüfrolle für alle Kernel-Funktionen gerecht werden kann.

Hardware-Plattformen: Kernel läuft auf Apples M1

Mit Apple M1 erhält Linux 5.13 einen prominenten Neuzugang. Der Linux-Kernel lässt sich für den neuen ARM-basierten, aber Apple-spezifischen Prozessor kompilieren. Linux 5.13 läuft somit grundsätzlich auf den 2020er ARM-basierten Ausgaben von Mac Mini, MacBook Pro und MacBook Air.

Damit ist Apples eigene ARM-Hardware zwar im Mainline-Kernel angekommen, für den produktiven Einsatz ist Linux auf dieser Plattform aber noch nicht geeignet. Deutlich ist das beispielsweise daran zu sehen, dass es die M1 GPU noch nicht in den Mainline-Kernel geschafft hat. Die M1-Grafik ist mit Linux 5.13 noch nicht Hardware-beschleunigt.

Bei den anderen Hardware-Plattformen bekommt 32-Bit-PowerPC das Debugging-System KFENCE und eBPF spendiert. Zudem unterstützen PowerPC-Systeme nun Time-Namespaces, mit denen sich Abweichungen zur Systemzeit für Namespaces und Container definieren lassen.

RISC-V bekommt kexec und insbesondere Crash-Dumps (Speicherabzüge) über kexec spendiert. kexec (kernel execute) dient zum Laden eines anderen Kernel aus einem laufenden heraus, was den Start eines neuen Kernels beschleunigt und in Hochverfügbarkeitsszenarien eine Rolle spielt.

Zusätzlich beherrscht Linux 5.13 auf RISC-V nun auch Execute-in-place (XIP). Das im Embedded-Umfeld begehrte Feature gestattet es, Programme aus ROM oder Flash-Memory direkt ablaufen zu lassen. Ohne XIP müssten die Programme zuerst aus ROM oder Flash ins RAM geladen und von dort aus gestartet werden. Zu guter Letzt rundet der Debugging-Mechanismus kprobes die Neuerungen bei RISC-V ab.

Dateisysteme

Der exFAT-Treiber kann jetzt mit dem ioctl()-Kommando FITRIM Laufwerke über nicht mehr benötigte Blöcke informieren. Zudem wurde das Auffinden von Dateien im Dateisystem (Look-up) beschleunigt. Mit gesetzter dirsync-Option lässt sich außerdem die Schreibgeschwindigkeit erhöhen.

XFS kann nun Speicherplatz von der letzten Allocation-Group entfernen. Da das Dateisystem aus einer Kette von Allocation-Groups besteht, lässt sich durch das Entfernen der letzten Gruppe die Kette verkürzen. Das ist ein erster Schritt das Dateisystem schrumpfen zu lassen. XFS kommt damit dem Ziel näher, online Dateisysteme zu schrumpfen. Neben dieser Grundlagenforschung erhält XFS mit dem neuen Kernel einige Performance-Verbesserungen.

Mit Linux 5.13 entfällt eine Einschränkung für das Dateisystem ext4: Dieses beherrscht jetzt auch die Dateisystemverschlüsselung, wenn Case-Folding aktiviert ist. Ist es eingeschaltet, unterscheidet ext4 – Unix-untypisch – nicht mehr zwischen Groß- und Kleinschreibung für das betreffende Dateisystem. Case-Folding und Verschlüsselung schlossen sich bislang aus; entweder das eine oder das andere. Des Weiteren überschreibt ext4 jetzt beim Löschen von Dateien, deren Verzeichniseinträge mit Nullbytes. Auf diese Weise begegnet das ext4-Team Datenschutzbedenken und verhindert das Offenlegen von Dateinamen und eventuell noch nicht überschriebenen Datenblöcken. Zudem verbessert sich auch die ext4-Performance.

Virtualisierung

Sowohl AMD als auch Intel haben ihre Architekturen um das Absichern und Verschlüsseln von virtuellen Maschinen erweitert. Die AMD Secure Encryption Virtualization (SEV) und die Intel Secure Guard Extensions (SGX) sollen verschlüsselte und abgesicherte Gastsysteme selbst auf kompromittierten Host-Systemen schützen. Gerade bei diesen für den virtualisierten Rechenzentrumsbetrieb wichtigen Features baut Linux 5.13 seine Unterstützung weiter aus.

Die neue KVM-API unterstützt die Live-Migration von Gastsystemen unter AMD Secure Encrypted Virtualization (SEV). Die Entwicklung in Linux 5.13 ist aber noch nicht vollständig, sodass 5.14 in diesem Punkt noch mal nachlegen wird. Neu hinzugekommen ist auch die Option, mehrere virtuelle Maschinen den gleichen Verschlüsselungskontext nutzen zu lassen.

Auf Intel-Plattformen ist es möglich, die Software Guard Extensions (SGX) nun auch in virtuellen Maschinen zu nutzen. Bei KVM verbessert und optimiert Linux 5.13 den neuen MMU-Code und bringt neue Virtio-Treiber für Bluetooth-Controller und Soundkarten mit.

Ausblick und weitere Informationen

Linux 5.13 ist sicherlich kein reines Standard-Update. Es enthält Neuerungen und versucht, neue Wege zu definieren. Auch für 5.14 sind die ersten Weichen gestellt. Einige neue Features sind erst "Zwischenstände" wie etwa die Live-Migration bei SEV und allen voran die Lauffähigkeit und Verfügbarkeit von Treibern für Apples M1-Systeme. Was genau die Kernel-Entwickler nachlegen, wird man in etwa zwei Wochen beim ersten Release-Candidate von Linux 5.14 sehen.

• Ankündigung von Linux 5.13 durch Linus Torvalds
• ChangeLog zu Linux 5.13
• Themenseite "Linux und Open-Source" bei heise online

(olb)