要約

  • RFC 9669 は BPF instruction と conformance group の共通語彙を定めるが、特定 program の verifier、load、attach、invoke を一括して保証しない。
  • hook が正しい program generation を参照し、実際に呼び出され、外部結果が一致したことまで、別々の identity と receipt が必要になる。

新しい program は verifier を通過した。load は program ID を返し、attach API も成功した。release 画面には三つの緑色の印が並んだ。

しかし、期待した packet path を流した後も invocation counter はゼロだった。link は存在したが、選択した hook はその traffic class では発火しなかった。安全な program object は、何も判断していなかった。

これは BPF の失敗ではない。証拠の主語を取り違えた deployment の失敗である。

RFC 9669 が固定するのは instruction の意味

BPF の basic instruction は 64 bit である。wide instruction は次の 64 bit を追加し、合計 128 bit になる。opcode、register、offset、immediate の解釈は instruction class によって決まる。この形式が共通なら、compiler と runtime は同じ byte sequence を同じ操作として扱える。

ただし、すべての実装がすべての instruction を持つ必要はない。RFC 9669 が必須とするのは base32 であり、追加 group は任意である。base64 は base32 を含み、atomic64 は atomic32 を、divmul64 は divmul32 を含む。group を support すると宣言するなら、その group の全 instruction を実装しなければならない。

IANA registry は group の name、description、includes、excludes、status、change controller、reference を保存する。instruction registry は opcode などの field pattern、semantics、所属 group と reference を保存する。新しい instruction は既存 group の意味を後から膨らませるのではなく、新しい group を作って追加する。

この仕組みは capability discovery を可能にする。しかし registry の Permanent は deployment 数ではない。割当てと変更手続が安定していることを示すのであって、手元の kernel、別 runtime、program type、あるいは NIC offload が実装済みだとは示さない。

「BPF 対応」という一語では compiler target を選べない。target ごとに group、version、architecture と時点を記録する必要がある。

定義済み opcode だけでは valid program にならない

RFC 9669 は composition の落とし穴も明示する。jump offset は 64-bit instruction 単位で数える。128-bit wide instruction の後半 word に着地すると undefined behavior になる。各 byte に既知の名前があっても、control flow 全体が実行可能とは限らない。

map、variable、function call も platform context を必要とする。ISA は抽象 operation を説明するが、具体的な object、identifier、helper surface は platform-specific documentation に委ねられる。一つの program type で許可された context field や function が、別の type でも使えるとは限らない。

RFC 9669 は verifier の役割として、合理的時間内の termination、安全な memory access、platform API contract、undefined behavior の排除を挙げる。その詳細は RFC の scope 外である。portable ISA と local admission policy を意図的に分けた境界だ。

Linux verifier は concrete example を与える。最初に control-flow graph を確認し、その後 possible path を追いながら register と stack の状態を simulation する。pointer だった register が不適切な演算で scalar になれば、次の memory access は拒否される。callback が program type ごとの context access と function prototype を決める。

Linux design Q&A は、program が実際に受理されるか知る方法として load を試すことを挙げる。verifier の知識と内部 limit は進化する。これは Linux の compatibility model であり、すべての runtime や hardware target に拡張できる普遍的約束ではない。

load、attach、invoke は三つの異なる event

verifier acceptance の後、loader が object を作れば program ID を得られる。ここで証明されたのは object の存在だ。link がどの hook にどの generation を結び付けたかは別に確認しなければならない。

attach が成功しても event が通らなければ invoke は起きない。interface、cgroup、namespace、program type などの selection が意図と違えば、正常な link が間違った reality を観測することもある。zero counter は「program が壊れた」とも「問題がなかった」とも単独では言えない。test event が正しい hook を通ったかを照合する必要がある。

invoke が増えても external outcome は残る。program-side map に deny が記録されても、別 path から packet が出たかもしれない。application の durable transaction や device state は BPF counter の外側にある。mechanism が自分で発行した receipt だけで自分の成功を閉じてはいけない。

Linux の現在の BPF signing documentation も層を分けている。valid signature は定義された範囲の authenticity と integrity を示すが、permission と verifier を置き換えない。早い admission hook で BPF_SIG_VERIFIED でも、まだ loaded とは限らない。これは Linux 固有の例であって RFC 9669 の必須機能ではないが、receipt の subject を限定する好例である。

generation を中心に receipt を結ぶ

運用 record には source/build input、object hash、compiler feature selection、target runtime、architecture、program type、発見した group、relocation と object binding、verifier verdict と log hash、program ID、link ID、hook、map generation、attach/detach time、invocation counter、program decision、そして independent outcome を含める。

特に replacement では generation を省略できない。新 object を load しただけで old link は消えない場合がある。map を再利用すれば counter が混ざる。policy name だけで join する dashboard は、新しい metadata と古い execution を一つの成功状態に見せる。

unsupported group、relocation failure、verifier rejection、load failure、attach failure、zero invocation、outcome mismatch は異なる negative receipt である。これらを一つの error code に潰すと、toolchain、runtime、orchestrator、traffic selection、application のどこを直すべきか分からなくなる。

RFC 9669 の価値は狭いからこそ大きい。instruction semantics と extension governance を共有し、optional capability と execution policy は local decision のまま残す。running code の信頼は、その先の receipt chain で作る。

出典