qmonnet/rbpfRust-Virtualmaschine und JIT-Compiler für eBPF-Programme
Rust (User-Space) virtuelle Maschine für eBPF
Dieses Crate enthält eine virtuelle Maschine zur Ausführung von eBPF-Programmen. BPF, wie in Berkeley Packet Filter, ist eine assemblerähnliche Sprache, die ursprünglich für BSD-Systeme entwickelt wurde, um Pakete im Kernel mit Werkzeugen wie tcpdump zu filtern und so unnötige Kopien in den User-Space zu vermeiden. Sie wurde auf Linux portiert, wo sie sich zu eBPF (extended BPF) entwickelte, einer schnelleren Version mit mehr Funktionen. Während BPF-Programme ursprünglich für die Ausführung im Kernel gedacht sind, ermöglicht die virtuelle Maschine dieses Crates deren Ausführung in User-Space-Anwendungen; sie enthält einen Interpreter, einen x86_64-JIT-Compiler für eBPF-Programme sowie einen Disassembler.
Sie basiert auf Rich Lanes uBPF-Software, die fast dasselbe tut, aber in C geschrieben ist.
Das Crate soll unter Linux, MacOS X und Windows kompilieren und laufen, obwohl der JIT-Compiler derzeit nicht mit Windows funktioniert.
Dieses Crate ist auf crates.io verfügbar, sodass es
out of the box funktionieren sollte, indem man es als Abhängigkeit in die Cargo.toml-Datei
einfügt:
[dependencies]
rbpf = "0.4.1"
Du kannst auch die Entwicklungsversion aus diesem GitHub-Repository verwenden. Dies
sollte so einfach sein, wie Folgendes in deine Cargo.toml einzufügen:
[dependencies]
rbpf = { git = "https://github.com/qmonnet/rbpf" }
Natürlich kannst du es, wenn du möchtest, lokal klonen, möglicherweise die Crate hacken
und dann den Pfad deiner lokalen Version in Cargo.toml angeben:
[dependencies]
rbpf = { path = "path/to/rbpf" }
Dann gib in deinem Quellcode an, dass du das Crate verwenden möchtest:
extern crate rbpf;
Die API ist im Quellcode recht gut dokumentiert. Sie sollten auch in der Lage sein, eine Online-Version der Dokumentation von hier aus aufzurufen, die automatisch aus der crates.io-Version generiert wird (möglicherweise nicht auf dem neuesten Stand des Hauptzweigs). Beispiele und Unit-Tests sollten ebenfalls hilfreich sein. Hier ist eine Zusammenfassung, wie das Crate verwendet wird.
Hier sind die Schritte, die zu befolgen sind, um ein eBPF-Programm mit rbpf auszuführen:
eBPF wurde ursprünglich entwickelt, um Pakete zu filtern (inzwischen hat es einige andere Hooks im Linux-Kernel, wie kprobes, aber dies wird von rbpf nicht abgedeckt). Infolgedessen werden die meisten Lade- und Speicheranweisungen des Programms auf einem Speicherbereich ausgeführt, der die Paketdaten repräsentiert. Im Linux-Kernel greift das eBPF-Programm jedoch nicht sofort auf diesen Datenbereich zu: Zunächst hat es Zugriff auf eine C-struct sk_buff stattdessen, die ein Puffer ist, der Metadaten über das Paket enthält – einschließlich Speicheradressen des Anfangs und des Endes des Paketdatenbereichs. Das Programm lädt also zunächst diese Zeiger aus der sk_buff und kann dann auf die Paketdaten zugreifen.
Dieses Verhalten kann mit rbpf nachgebildet werden, ist aber nicht zwingend erforderlich. Aus diesem Grund haben wir mehrere Structs, die verschiedene Arten von virtuellen Maschinen repräsentieren:
struct EbpfVmMbuffer ahmt den Kernel nach. Wenn das Programm ausgeführt wird, ist die Adresse, die an sein erstes eBPF-Register übergeben wird, die Adresse eines vom Benutzer bereitgestellten Metadatenpuffers, von dem erwartet wird, dass er Zeiger auf den Anfang und das Ende des Paketdaten-Speicherbereichs enthält.
struct EbpfVmFixedMbuff hat einen Zweck: die Ausführung von Programmen zu ermöglichen, die für die Kompatibilität mit dem Kernel erstellt wurden, während dem Benutzer die manuelle Handhabung des Metadatenpuffers erspart wird. Tatsächlich hat diese Struct einen statischen internen Puffer, der an das Programm übergeben wird. Der Benutzer muss die Offset-Werte angeben, an denen das eBPF-Programm erwartet, den Anfang und das Ende der Paketdaten im Puffer zu finden. Beim Aufruf der Funktion, die das Programm ausführt (JIT-kompiliert oder nicht), aktualisiert die Struct automatisch die Adressen in diesem statischen Puffer an den festgelegten Offsets für den Anfang und das Ende der Paketdaten, für die das Programm aufgerufen wird.
struct EbpfVmRaw ist für Programme, die direkt auf Paketdaten ausgeführt werden sollen. Es ist kein Metadatenpuffer beteiligt, das eBPF-Programm erhält die Adresse der Paketdaten direkt in seinem ersten Register. Dies ist das Verhalten von uBPF.
struct EbpfVmNoData nimmt keine Daten entgegen. Das eBPF-Programm nimmt überhaupt keine Argumente entgegen und sein Rückgabewert ist deterministisch. Nicht ganz sicher, ob es einen gültigen Anwendungsfall dafür gibt, aber wenn nichts anderes, ist dies sehr nützlich für Unit-Tests.
Alle diese Structs implementieren dieselben öffentlichen Funktionen:
// called with EbpfVmMbuff:: prefix
pub fn new(prog: &'a [u8]) -> Result<EbpfVmMbuff<'a>, Error>
// called with EbpfVmFixedMbuff:: prefix
pub fn new(prog: &'a [u8],
data_offset: usize,
data_end_offset: usize) -> Result<EbpfVmFixedMbuff<'a>, Error>
// called with EbpfVmRaw:: prefix
pub fn new(prog: &'a [u8]) -> Result<EbpfVmRaw<'a>, Error>
// called with EbpfVmNoData:: prefix
pub fn new(prog: &'a [u8]) -> Result<EbpfVmNoData<'a>, Error>
Dies wird verwendet, um eine neue Instanz einer VM zu erstellen. Der Rückgabetyp hängt von
der Struktur ab, von der aus die Funktion aufgerufen wird. Zum Beispiel würde
rbpf::EbpfVmRaw::new(Some(my_program)) eine Instanz von struct rbpf::EbpfVmRaw zurückgeben (verpackt in einem Result). Wenn ein Programm geladen wird, wird es
mit einem sehr einfachen Verifier geprüft (nichts Vergleichbares zu dem für den Linux-
Kernel). Benutzer können ihn auch durch einen benutzerdefinierten Verifier ersetzen.