BPFのアーキテクチャ、命令セット、cBPFとeBPFの違い：Berkeley Packet Filter（BPF）入門（2）（2/2 ページ）

命令セットの詳細

　ここでは命令のオペコード（上の「sturct cbpf_insn」「struct ebpf_insn」の「code」の値）について説明します。eBPFはcBPFのオペコードを基本的に受け継いでおり、その上で一部命令が変更、追加されています。

　まず、オペコードは下位3bitによって、下記のようなクラスに分けられます。

　eBPFではBPF_RETクラスは使用されていません。また、BPF_MISCクラスはBPF_ALU64クラスに変更されています。

BPF_ALU、BPF_JMPクラス

　クラスが「BPF_ALU」「BPF_JMP」のとき、オペコードは下記のような構成をとります。なおcBPFの命令では、オペコードは16bit幅ですが、実際には下位8bitしか利用されていません。

　ここで、sourceの値によりソースオペランドとして何が利用されるかが決まります。

　ディスティネーションはcBPFの場合はAレジスタ、eBPFの場合はdst_regのレジスタになります。BPF_ALUのとき、operation codeは下記のようになります。

　operation code、source、instruction classの組み合わせで命令が決定します。例えば、「BPF_ALU | BPF_X | BPF_ADD」はcBPFでは「A += X」、eBPFでは「dst_reg = (u32)dst_reg + (u32) src_reg」という意味になります。

　BPF_ENDは、BPF_ALUクラスの中でも特殊な命令であり、下記のようになります。

• sourceの値が0（BPF_TO_LE）のとき、リトルエンディアンへ変換
• sourceの値が1（BPF_TO_BE）のとき、ビッグエンディアンへ変換
• immの値でビット幅を指定（16、32、64のいずれか）

　例えば、「BPF_ALU | BPF_TO_LE | BPF_END」かつimmが32のとき、「dst_reg = (u32) cpu_to_le32(dst_reg)」という意味になります。

　BPF_JMPのとき、operation codeは下記のようになります。

　例として、「BPF_JGE | BPF_K | BPF_JMP」はcBPFでは「pc += (A >= k) ? jt : jf」という意味になります。eBPFでは「pc += (dst_reg >= imm) ? off : 0」という意味になります。

BPF_ALU64クラス

　eBPFにはBPF_ALU64クラスがあります。このクラスのときBPF_ALUクラスと同一の命令が利用できますが、計算は64bitで行われます。

　例えば、「BPF_ADD | BPF_X | BPF_ALU64」は「dst_reg = dst_reg + src_reg」という意味になります。

BPF_LD、BPF_LDX、BPF_ST、BPF_STX クラス

　「BPF_LD」「BPF_LDX」「BPF_ST」「BPF_STX」のとき、オペコードは下記の構成をとります。

　ここで、size、modeは下記の意味になります。

　全ての命令の組み合わせが許可されているわけではありません。cBPFで許可されるのは下記の命令です。

　ここで、「P[]」はcBPFプログラムに渡される引数（通常はパケットデータ）になります。なお、「BPF_MSH」はIPv4ヘッダ内のヘッダ長に効率良くアクセスするための命令です。

　cBPFではロード命令（「BPF_LD | BPF_ABS」）において、特別なオフセット値を用いることで、パケットのメタデータなどにアクセスすることが可能です。この機能は「BPF extension」と呼ばれます。下記にBPF extensionに利用されるオフセットと意味を示します。

　ここで、「skb」はカーネル内のパケットデータ構造である「struct sk_buff」を意味します。フィルタリング時にcBPFに渡される引数は、実質的に「skb->data」になります。

　注意点として、「skb->data」はパケットがネットワークスタックのどこに位置するかで異なります。例えば、raw socketに対してBPFプログラムをアタッチした場合、BPFプログラムが呼ばれるのはL2スタック処理段階であり、このとき「skb->data」はL2のフレーム先頭になります。一方で、通常のsocketに対してBPFプログラムをアタッチした場合、「skb->data」はL4ヘッダ先頭になります。このときL2のフレーム先頭やL3のヘッダ先頭にアクセスしたい場合、下記の特殊なオフセットが利用できます。

　eBPFでは、汎用的なロードストア命令がサポートされています。下記にeBPFで使用できる命令を示します。

　「BPF_LD | BPF_DW |BPF_IMM」では64bit即値を表現するために、2つの連続した「struct bpf_insn」を利用します。最初の「bpf_insn.imm」で下位32bit、次の「bpf_insn.imm」で上位32bitを表現します。これはeBPFで唯一の16バイト命令になります。32bit即値のロードには「BPF_ALU | BPF_K | BPF_MOV」を利用します。

eBPFにおけるBPF_ABS、BPF_IND

　もともとcBPFでは「BPF_LD | BPF_ABS」や「BPF_LD | BPF_IND」の一命令でパケットデータをロードしていました。このときエンディアンはホストオーダーに自動で変換されます。

　一方eBPFをネットワーク関連のイベントにアタッチした場合、コンテキストとして渡される引数はsk_buffです。eBPFでは汎用的なメモリアクセス命令（「BPF_LDX | BPF_MEM」）が存在するため、理論的にはこの命令を利用してsk_buff内のパケットデータにアクセスできます。

　しかし、eBPF導入当初は直接sk_buff内のパケットデータに直接アクセスすることはできませんでした。この理由の一つは、検証器がメモリアクセスが正しい範囲内に収まっているかを静的に検証することが簡単ではないためだと思われます。

　eBPFでも「BPF_LD | BPF_ABS」や「BPF_LD | BPF_IND」を利用してエンディアンがホストオーダーに変換済みのパケットデータをロードできます。

　ただし、これらは他の命令と比べて特殊な命令となっており、命令実行前にR6にコンテキスト（sk_buff）の値を入れておく必要があります。結果はR0に格納されます。

　例えば、「BPF_IND | BPF_W | BPF_LD」は、「R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32))」という意味になります。この命令は内部では関数呼び出し（「bpf_skb_load_helper*()」）として実行されます（従って、命令実行前にR1〜R5のレジスタは必要に応じて退避する必要があります）。この関数の中では動的にオフセットの境界チェックを行っており、仮に境界外アクセスをしようとした場合はその時点でプログラムの実行が終了し、0が戻り値として返されます。

　今では、パフォーマンスを向上させるためには、XDPなどではBPFプログラムから直接パケットデータにアクセスする「Direct Packet Access」が利用できます。Direct Packet Accessについては次回の「検証器の説明」の際に詳しく触れます。

　なおコンテキストがsk_buff以外の場合、BPF_ABSやBPF_INDを使った命令は利用できません（検証器が実行を許可しません）。

BPF_RETクラス

　cBPFにはBPF_RETクラスが存在します。BPF_RETクラスではオペコードは下記の構成をとります。

　sourceによってcBPFプログラムが関数終了時に返す値を指定します。Xレジスタの値を返すことはできません。

　eBPFではリターンには「BPF_JMP | BPF_EXIT」を利用します。このとき、戻り値はR0に格納します。

BPF_MISCクラス

　cBPFにはBPF_MISCクラスが存在します。BPF_MISCクラスではオペコードは下記の構成をとります。

　eBPFではBPF_MISCクラスは利用されていません。レジスタ間の移動には「BPF_ALU | BPF_X | BPF_MOV」を利用します。

次回は、BPFプログラムの作成方法、BPFの検証器、JITコンパイル機能

　今回は、BPFの基礎としてBPFのアーキテクチャについて説明しました。次回も引き続き基礎として、BPFプログラムの作成方法、BPFの検証器およびJITコンパイル機能などについて説明します。