Ingenieurinnen und Ingenieure verwenden eBPF, um das Verhalten des Linux-Kernels ohne Kernel-Module zu untersuchen

Dan Fineran, leitender Community-Advocate bei Isovalent bei Cisco, sagte gegenüber InfoQ, dass Entwickler eBPF inzwischen weit über das Packet-Filtering hinaus einsetzen, wobei Teams es für Linux-Observability, Kubernetes-Networking, Syscall-Durchsetzung und frühe Windows-Experimente verwenden.

Kernel-Entwickler haben eBPF aus dem älteren Berkeley-Packet-Filter-Modell entwickelt. Das ursprüngliche BPF gab Administratoren eine Möglichkeit, Pakete zu filtern. eBPF übernahm die Idee kleiner Programme, die an Kernel-Hooks angehängt werden, und erweiterte das Modell dann zu einer breiteren Erweiterungsschicht.

Fineran sagte, der Reiz beginne mit dem Linux-Contribution-Pfad. Ein Team, das neues Kernel-Verhalten möchte, kann einen Patch schreiben, Reviews von Subsystem-Maintainern einholen, auf die Aufnahme in den Kernel warten und dann erneut warten, bis Distributionen wie Ubuntu oder Red Hat diesen Kernel ausliefern. Dieser Weg schützt Linux-Nutzer, verlangsamt aber Teams, die jetzt Produktions-Einblick oder Durchsetzung brauchen.

Teams können auch Kernel-Module schreiben, aber dieser Weg bringt Versionskopplung und Absturzrisiko mit sich. Ein Modulautor kompiliert oft gegen eine bestimmte Kernelversion. Schlechter Modulcode kann die Ausführung blockieren oder einen Host zum Absturz bringen. eBPF gibt Entwicklern ein kleineres Ziel mit stärkeren Leitplanken.

Die Leitplanke, die Fineran hervorhob, ist der Verifier. Entwickler kompilieren eBPF-Code zu Bytecode und bitten dann den Kernel, ihn zu laden. Der Verifier prüft Speicherzugriffe, Schleifenbegrenzungen und Programmlaufzeitverhalten, bevor der Kernel das Programm akzeptiert. Findet der Verifier unsichere Zugriffe oder einen Ausführungspfad, der ohne Begrenzung laufen kann, lehnt er das Programm ab.

Dieses Modell gibt Plattformingenieuren einen Hot-Deploy-Pfad für Kernel-Level-Verhalten. Man kann Code an unterstützte Hooks auf einem laufenden System anhängen und ihn entfernen, ohne den Kernel neu zu bauen. Man braucht weiterhin Low-Level-Fähigkeiten, oft in C und inzwischen häufiger mit Rust-Tooling, vermeidet aber das Betriebsrisikoprofil eines vollständigen Kernel-Moduls.

Fineran wandte sich auch gegen die Vorstellung, Entwickler müssten eBPF lernen, bevor sie eBPF-basierte Tools nutzen können. Cilium, das Kubernetes-Networking-Projekt von Isovalent, verbirgt einen Großteil dieser Mechanik hinter Policy- und Service-Abstraktionen. Betreiber definieren, welche Workloads miteinander kommunizieren dürfen. Cilium-Ingenieure nutzen eBPF unter der Haube, um Pakete zu lenken und Policies durchzusetzen.

Dasselbe Muster gilt für Tetragon, das Isovalent-Ingenieure für Runtime-Sicherheit und Observability entwickelt haben. Sicherheitsteams können Tetragon-Policies nutzen, ohne rohe eBPF-Programme zu schreiben. Tetragon hängt an Syscalls und anderen Kernel-Hooks, zeichnet Aktivität auf und kann bestimmte Aktionen blockieren, bevor der Kernel sie abschließt.

Dieses Pre-Hook-Modell verändert den Sicherheitsbetrieb. Ein herkömmlicher Agent protokolliert möglicherweise das Löschen einer Datei oder eine Privilegeskalation erst, nachdem der Kernel die Aktion abgeschlossen hat. Mit eBPF kann ein Sicherheitsteam Logik vor einen Syscall setzen und die Operation stoppen. Fineran nannte Beispiele wie das Blockieren von Löschungen in einem geschützten Projektverzeichnis, das Einschränken des Zugriffs auf Datenbankdateien auf den Datenbank-Daemon oder das Verhindern von Privilegeskalation außerhalb genehmigter Pfade.

Ingenieure können Tetragon-Policies auch nutzen, um bekannte Schwachstellenmuster abzumildern. Wenn ein Team weiß, dass eine verwundbare Funktion Eingaben oberhalb einer bestimmten Größe falsch verarbeitet, kann es eine Policy vor dem verwundbaren Pfad anhängen und Eingaben ablehnen, die dem Exploit-Muster entsprechen. Das ersetzt kein Patchen, gibt Operations-Teams aber eine Möglichkeit, das Risiko zu reduzieren, während Application-Owner dauerhafte Fixes vorbereiten.

Fineran verband denselben Mechanismus mit Observability. Entwickler können Programme an Kernel-Probes, Return-Probes, Tracepoints, Syscalls und User-Space-Probes anhängen. Das gibt Teams Einblick in Dateizugriffe, Netzwerkaufrufe, Bibliotheksaufrufe, Storage-Pfade und Treiberverhalten, ohne für jede Anwendung Instrumentierungsbibliotheken hinzuzufügen.

GPU-Auslastung lieferte ein Beispiel. Fineran beschrieb Teams, die eBPF-Programme in der Nähe von NVIDIA-CUDA-Treiberpfaden anhängen, um Low-Level-Aktivität auszulesen und mit der Workload-Nachfrage zu korrelieren. Plattformteams können dieses Signal nutzen, um teure Beschleuniger auszulasten und verschwendete Kapazität zu reduzieren.

Entwickler müssen dennoch die Grenzen verstehen. Der Verifier beschränkt Programmgröße, Schleifenverhalten und Speicherzugriffe. Fehlermeldungen können für neue Nutzer anspruchsvoll sein, besonders wenn der Verifier dichte Diagnosen zurückgibt. Fineran sagte, die Community habe Tools und Dokumentation verbessert, darunter Liz Rices Learning eBPF und die eBPF community resources.

Microsoft hat außerdem über das Projekt eBPF for Windows einen Weg für eBPF unter Windows eröffnet. Linux-Nutzer erhalten eBPF-Unterstützung direkt im Kernel, während Windows-Nutzer weiterhin zusätzliche Treiber benötigen. Fineran sagte, diese plattformübergreifende Richtung könne Organisationen helfen, Observability und Policies über gemischte Betriebssysteme hinweg zu vereinheitlichen.

Das Gespräch berührte auch Micro-VMs und Kubernetes-Isolation. Fineran sagte, Teams könnten Kernel-Isolation mit eBPF-basierten Runtime-Kontrollen kombinieren. Micro-VMs reduzieren das Risiko eines gemeinsam genutzten Kernels, während Tetragon weiterhin Verhalten in unterstützten Gastumgebungen inspizieren und durchsetzen kann. Edera, sagte er, habe eBPF-Unterstützung innerhalb seines Micro-VM-Kernels hinzugefügt.

KI-gestützte Operations kamen als zukünftiger Weg zur Sprache. Fineran sagte, Cisco und die Community hätten mit modellgenerierten Tetragon-Policies experimentiert, obwohl aktuelle Modelle Policy-Felder erzeugen können, die plausibel aussehen und bei der Validierung scheitern. Er beschrieb einen wahrscheinlichen Workflow, in dem ein Vulnerability-Tool eine Exploit-Form identifiziert, ein Modell eine Policy entwirft und ein menschliches oder automatisiertes Validierungssystem die Policy vor dem Rollout testet.

Dieser Workflow verlangt Prüfung. Fineran warnte, dass Open-Source-Nutzer die Stärke der Maintainer, die Aktualisierungsfrequenz, die Support-Tiefe und die Code-Herkunft prüfen sollten, bevor sie eBPF-Projekte übernehmen. KI-generierter Code kann das Beitragsvolumen erhöhen, aber Projektverantwortliche brauchen weiterhin genug Verständnis, um Fehler zu beheben, Nutzer zu unterstützen und das Projekt nach Änderungen an Modellen oder Tooling zu pflegen.

Für die meisten Entwickler bleibt eBPF ein Implementierungsdetail in Tools wie Cilium und Tetragon. Für Plattform-, Sicherheits- und Observability-Teams bietet es eine direkte Möglichkeit, das Systemverhalten an der Kernel-Grenze zu inspizieren und zu formen, ohne Kernel-Module auszuliefern oder auf Upstream-Kerneländerungen zu warten.