Summary

  • RFC 9669 gives compilers and runtimes a stable BPF instruction vocabulary and named conformance groups; it does not make every registered instruction mandatory.
  • A supported opcode is only the first receipt. Verifier acceptance, object load, hook attachment, invocation and the intended application or network effect remain distinct facts.

The fleet record was compact: “BPF supported.” The build system read that label, emitted a 64-bit atomic operation and produced a valid object. The target accepted the object far enough to mint a program identifier. The rollout controller then marked the enforcement policy active.

Traffic continued through the path that the policy was supposed to govern. The new program’s counter stayed at zero. A stale link still pointed to the previous generation.

Nothing in that sequence contradicts the instruction-set architecture. It exposes a category error. An ISA describes how instructions are encoded and what their abstract operations mean. It does not certify the life cycle of one program on one hook.

A registry entry is a coordinate, not a deployment fact

RFC 9669 standardizes two instruction widths. A basic instruction occupies 64 bits; a wide instruction adds a second 64-bit word. Opcode, register, offset and immediate fields are interpreted according to their class. That common grammar lets a compiler and runtime identify the same operation without sharing a source language.

The RFC deliberately avoids saying that every implementation must execute every listed instruction. It requires the base32 conformance group and permits additional groups. base64 includes base32; atomic64 includes atomic32; divmul64 includes divmul32. Supporting a named group means supporting all instructions in that group.

That is useful precision. “Supports BPF” is too broad for scheduling. A compiler needs to know whether a target covers the exact instruction family it may emit. A runtime needs a bounded claim it can test and publish. IANA records the group name, inclusion and exclusion relations, status, controller and reference, while the instruction registry binds field patterns to descriptions and groups.

The registry still says nothing about a particular machine today. A Permanent entry means the assignment has a stable standards-controlled home. It does not mean that every runtime implements it, that an administrator enabled it, or that a hardware offload target accepts it. Capability discovery must end in target-specific evidence.

Whole-program validity begins where the ISA stops

An instruction can be defined and supported while the program containing it remains invalid. RFC 9669 gives a sharp example: branch offsets are counted in 64-bit instruction units. A jump that lands in the second word of a 128-bit instruction produces undefined behavior. The bytes may use familiar opcodes, yet their composition has no safe program meaning.

Memory, control flow and platform functions add further context. Map references and callable functions are not resolved by the opcode table alone. Concrete availability comes from the execution platform and program type. The same instruction sequence can therefore meet the ISA vocabulary while failing a target’s memory, helper or context contract.

RFC 9669 describes verifiers as checking termination, safe memory interaction, platform API contracts and undefined behavior, then puts verifier details outside the document’s scope. That is not an omission to be filled with assumption. It is a boundary between a portable machine-language contract and local admission policy.

Linux illustrates the distinction. Its verifier first validates control flow, then symbolically explores paths while tracking registers and stack state. Program-type callbacks determine which context fields and callable functions are valid. A register that is readable in one state may be unusable in another. An address within an instruction’s numeric range may still violate a memory-type or alignment rule.

The Linux design documentation offers an unusually honest operational test: the practical way to know whether a program will be accepted is to try loading it. A static inventory of opcodes cannot substitute for that verdict.

Authenticity does not collapse admission

Current Linux signing documentation provides another clean separation. A valid program signature establishes the authenticity and integrity coverage defined by that mechanism. It does not replace capability checks or the verifier. At an early admission hook, BPF_SIG_VERIFIED means “validly signed,” not “fully loaded.” A later verifier or object-binding check can still reject the program.

This is a Linux implementation example, not a rule imposed by RFC 9669. Its value is analytical: a strong receipt should retain its exact subject. Signature valid, verifier accepted and program loaded are three statements, not three spellings of “safe.”

The same discipline applies after load. A program identifier shows that an object exists. It does not show that the desired hook links to it. A link record shows attachment, but not that the hook has fired. An invocation counter shows execution, but not that a policy decision altered the intended packet or application transaction. A program-side map is still evidence produced inside the mechanism under test.

Build a chain that survives a mixed generation

A defensible rollout records the source and build inputs, exact object or instruction hash, compiler feature selection, target runtime and architecture, claimed conformance groups, resolved maps and platform functions, verifier verdict and diagnostic hash, loaded program identity, hook or link identity, attach and detach times, invocation counters, program-side decision state and an independent outcome.

Generation matters at every edge. If a new object loads while an old link remains attached, a dashboard that joins only by policy name will manufacture success. If maps survive replacement, counters may combine two generations. If the verifier log is discarded after a retry, operators lose the reason one target diverged from the fleet.

Negative receipts deserve equal status: unsupported group, relocation failure, verifier rejection, load failure, attach failure, zero invocation and outcome mismatch. They distinguish a capability problem from a control-flow problem and a control-flow problem from an application result.

The narrow achievement of RFC 9669 is worth protecting. It supplies a minimum shared language for instruction semantics and controlled extension. That language becomes more credible when operators refuse to make it promise more than it does.

Sources