Zusammenfassung

  • RFC 9669 standardisiert BPF-Instruktionsformate und Conformance Groups, aber eine Liste unterstützter Opcodes validiert weder Kontrollfluss noch Plattformvertrag eines ganzen Programms.
  • Nach der ISA-Kompatibilität folgen Verifier-Entscheidung, Objekt-Load, Hook-Attach, tatsächliche Invocation und unabhängige Wirkung als eigene Belegstufen.

Der Kompatibilitätstest verglich die Opcodes des Artefakts mit der Capability-Liste des Ziels. Alle Werte waren bekannt. Die Pipeline erklärte das Objekt für portabel.

Der Verifier lehnte es ab. Ein relativer Sprung landete nicht auf der nächsten Instruktion, sondern auf dem zweiten 64-Bit-Wort einer Wide Instruction. Die Teile waren definiert; ihre Verbindung erzeugte undefined behavior.

Eine Wortliste hatte versucht, einen Satz zu prüfen.

Die ISA stabilisiert Bedeutung, nicht jeden Programmzustand

RFC 9669 beschreibt ein Basic Encoding mit 64 Bit und ein Wide Encoding mit insgesamt 128 Bit. Opcode, Register, Offset und Immediate erhalten ihre Bedeutung aus der Instruktionsklasse. Compiler und Runtime können damit dieselbe Bytefolge als dieselbe abstrakte Operation verstehen.

Nicht jede Implementierung muss alle Instruktionen unterstützen. base32 ist verpflichtend, weitere Gruppen sind optional. base64 schließt base32 ein, atomic64 schließt atomic32 ein, und divmul64 schließt divmul32 ein. Wer eine Gruppe unterstützt, muss sämtliche Instruktionen dieser Gruppe beherrschen.

Die IANA-Registries halten diese Aussagen dauerhaft auseinander. Eine Group-Registrierung enthält Namen, Beschreibung, Includes, Excludes, Status, Change Controller und Referenz. Eine Instruction-Registrierung ordnet Feldkombinationen einer Beschreibung und Gruppen zu. Erweiterungen erhalten neue Gruppen, statt bestehende Versprechen nachträglich auszuweiten.

Permanent bedeutet deshalb eine kontrollierte Zuweisung, nicht flächendeckende Implementierung. Ein installiertes Ziel kann nur base32 anbieten und dennoch standardkonform sein. Ein Kernel und ein Hardware-Offload können unterschiedliche optionale Gruppen besitzen. Capability Discovery braucht Ziel, Version, Architektur und Zeitpunkt.

Auch Historical bedeutet nicht, dass alte Bytes verschwinden. Die deprecated Packet-Access-Instruktionen bleiben beschrieben, gehören aber zur Historical-Gruppe packet. Ein Legacy-Runtime darf sie noch verstehen; ein neuer Compiler darf daraus keine universelle Baseline ableiten.

Ein zulässiges Vokabular kann ungültigen Kontrollfluss bauen

Sprung-Offsets werden in Einheiten von 64-Bit-Instruktionen relativ zur folgenden Instruktion gezählt. Überspringt ein Sprung nur das erste Wort einer 128-Bit-Instruktion, landet der Program Counter in deren zweitem Wort. RFC 9669 bezeichnet das Ergebnis als undefined behavior.

Damit ist die zentrale Grenze sichtbar. Gruppen beantworten, welche Operationen ein Ziel verstehen muss. Sie beantworten nicht, ob Branch Targets, Registerzustände, Stack-Nutzung und Speicherzugriffe des konkreten Programms gültig sind.

Maps, Variablen und Function Calls fügen Plattformabhängigkeit hinzu. Die ISA beschreibt abstrakte Auflösungsschritte, doch konkrete Objekte und aufrufbare Funktionen stammen aus plattformspezifischer Dokumentation. Ein Helper, der für einen Program Type zulässig ist, kann in einem anderen Context fehlen.

RFC 9669 nennt Verifier-Aufgaben: Terminierung, sichere Speicherinteraktion, Einhaltung von Plattform-API-Verträgen und Ausschluss undefinierten Verhaltens. Die Details liegen ausdrücklich außerhalb seines Geltungsbereichs. Das schützt die portable Instruktionssprache davor, mit einer einzigen lokalen Admission Policy verwechselt zu werden.

Linux zeigt eine konkrete Ausprägung. Der Verifier prüft zunächst den Kontrollfluss und simuliert danach mögliche Pfade. Er verfolgt Registertypen und Stack-Zustand. Ein Pointer kann durch eine Operation zu einem Scalar werden; ein numerisch plausibler Zugriff kann wegen Typ, Alignment oder Grenzen unzulässig sein. Program-Type-Callbacks bestimmen Context-Felder und Function Prototypes.

Die Linux Design Q&A fasst die operative Konsequenz zusammen: Ob ein bestimmtes Programm akzeptiert wird, zeigt der Load-Versuch. Interne Grenzen und Analysewissen verändern sich. Linux-Kompatibilität für früher akzeptierte Programme ist kein Versprechen für jeden Runtime, Offload oder lokalen Policy-Satz.

Verifier-Erfolg ist noch kein Attach

Ein akzeptiertes Programm kann geladen und mit einer Program ID versehen werden. Dieser Beleg betrifft das Objekt. Erst ein Link bindet eine bestimmte Generation an einen bestimmten Hook. Ein vorhandener Link wiederum beweist keine Invocation. Vielleicht passierte kein Event den Hook, vielleicht wurde die falsche Interface-, Namespace- oder Cgroup-Grenze gewählt.

Steigt ein programminterner Counter, bleibt die Außenwirkung offen. Ein Map-Eintrag kann eine getroffene Entscheidung zeigen, aber keinen parallelen Pfad ausschließen. Für Netzwerkpolitik braucht es eine unabhängige Beobachtung des Testflusses; für Anwendungspolitik einen dauerhaften Transaktionszustand.

Auch eine Signatur ist eine eigene Ebene. Die aktuelle Linux-Dokumentation erklärt BPF Signing als orthogonal zu Berechtigungen und Verifier. BPF_SIG_VERIFIED an einem frühen Admission Hook bedeutet gültig signiert, nicht vollständig geladen. Spätere Prüfungen können weiterhin ablehnen. Das ist ein Linux-Beispiel, keine RFC-9669-Pflicht, und gerade deshalb darf es nicht zur universellen Aussage werden.

Der Rollout braucht Generationen, nicht nur Namen

Eine belastbare Kette speichert Source- und Build-Input, Object Hash, Compiler Feature Set, Zielruntime und Architektur, Program Type, entdeckte Gruppen, Relocations, Verifier-Verdict und Log-Hash, Program ID, Link ID, Hook, Map-Generation, Attach- und Detach-Zeit, Invocation Counter, interne Entscheidung und unabhängiges Ergebnis.

Negative Belege müssen erhalten bleiben: fehlende Gruppe, ungültiges Branch Target, Relocation Failure, Verifier-Rejection, Load Failure, Attach Failure, Zero Invocation und Outcome Mismatch. Sie weisen auf unterschiedliche Kontrollflächen.

Bei Updates ist eine neue Program ID nicht gleichbedeutend mit Ablösung. Ein alter Link kann aktiv bleiben; eine wiederverwendete Map kann Counter verschiedener Generationen mischen. Ein Dashboard, das nur per Policy-Namen verbindet, legt dann neue Metadaten über alten Running Code.

Rollback verlangt daher eine vollständige Link-Inventur und eine definierte Map-Zuordnung. Das Löschen des jüngsten Objekts sagt weder, was weiterhin attached ist, noch ob der gewünschte Datenpfad wiederhergestellt wurde.

RFC 9669 setzt ein bewusst minimales gemeinsames Fundament. Es koordiniert Instruktionsbedeutung und Erweiterung, während optionale Fähigkeiten, Verifier-Regeln und Vertrauen lokale Entscheidungen bleiben. Der Standard wird stärker, wenn diese Grenze sichtbar bleibt.

Quellen