小さな子供のための BPF、パート XNUMX: 拡張 BPF

当初は BPF と呼ばれるテクノロジーがありました。 私たちは彼女を見た 前へ, このシリーズの旧約聖書の記事。 2013 年、Alexei Starovoitov と Daniel Borkman の努力により、最新の 64 ビット マシン向けに最適化された改良版が開発され、Linux カーネルに組み込まれました。 この新しいテクノロジーは、一時的に内部 BPF と呼ばれていましたが、その後拡張 BPF と名前が変更され、数年後の現在では、誰もが単に BPF と呼んでいます。

大まかに言えば、BPF を使用すると、ユーザーが指定した任意のコードを Linux カーネル空間で実行できるようになります。新しいアーキテクチャは非常に成功したため、そのアプリケーションをすべて説明するにはあと XNUMX 個の記事が必要になるでしょう。 (以下のパフォーマンス コードからわかるように、開発者がうまくできなかった唯一の点は、まともなロゴを作成したことです。)

この記事では、BPF 仮想マシンの構造、BPF を操作するためのカーネル インターフェイス、開発ツール、および既存の機能の簡単な概要について説明します。 将来、BPF の実際の応用をより深く研究するために必要なものがすべて含まれています。

記事のまとめ

BPF アーキテクチャの概要。 まず、BPF アーキテクチャを鳥瞰し、主要コンポーネントの概要を説明します。

BPF 仮想マシンのレジスタとコマンド システム。 アーキテクチャ全体のアイデアがすでに得られているので、BPF 仮想マシンの構造について説明します。

BPF オブジェクト、bpffs ファイル システムのライフ サイクル。 このセクションでは、BPF オブジェクト (プログラムとマップ) のライフ サイクルを詳しく見ていきます。

bpf システムコールを使用したオブジェクトの管理。 すでにシステムをある程度理解したので、最後に、特別なシステムコールを使用してユーザー空間からオブジェクトを作成および操作する方法を見ていきます- bpf(2).

Пишем программы BPF с помощью libbpf. もちろん、システムコールを使用してプログラムを作成することもできます。 しかし、それは難しいです。 より現実的なシナリオのために、核プログラマーはライブラリを開発しました。 libbpf。 後続の例で使用する基本的な BPF アプリケーション スケルトンを作成します。

カーネルヘルパー。 ここでは、BPF プログラムがカーネル ヘルパー関数にアクセスする方法を学びます。カーネル ヘルパー関数は、マップとともに、従来の BPF と比較して新しい BPF の機能を根本的に拡張するツールです。

BPF プログラムからマップへのアクセス。 この時点までに、マップを使用するプログラムを作成する方法を正確に理解するのに十分な知識が得られます。 そして、偉大で強力な検証ツールを簡単に覗いてみましょう。

開発ツール。 実験に必要なユーティリティとカーネルを組み立てる方法に関するヘルプ セクション。

結論。 ここまで読んだ人は、記事の最後に、やる気を起こさせる言葉と、次の記事で何が起こるかについての簡単な説明が表示されます。 続きを待つ意欲や能力がない人のために、自習用のリンクもいくつかリストします。

BPF アーキテクチャの概要

BPF アーキテクチャの検討を始める前に、最後にもう一度参照します (ああ)。 古典的なBPF、RISC マシンの出現に対応して開発され、効率的なパケット フィルタリングの問題を解決しました。 このアーキテクチャは非常に成功したため、バークレー UNIX で輝かしい XNUMX 年代に誕生してから、ほとんどの既存のオペレーティング システムに移植され、狂気の XNUMX 年代まで生き残り、今でも新しいアプリケーションを見つけ続けています。

新しい BPF は、64 ビット マシン、クラウド サービスの普及、および SDN を作成するツールのニーズの高まりに対応して開発されました (Sソフトウェア-d定義された nネットワーク化)。 古典的な BPF の改良された代替品としてカーネル ネットワーク エンジニアによって開発された新しい BPF は、文字通り XNUMX か月後に Linux システムをトレースするという困難なタスクに応用できることを発見しました。そして、その登場から XNUMX 年が経った今、次の記事が必要になるでしょう。さまざまな種類のプログラムをリストします。

面白い写真

BPF の核心は、セキュリティを損なうことなくカーネル空間で「任意の」コードを実行できるようにするサンドボックス仮想マシンです。 BPF プログラムはユーザー空間で作成され、カーネルにロードされて、何らかのイベント ソースに接続されます。 イベントには、たとえば、ネットワーク インターフェイスへのパケットの配信、カーネル関数の起動などが考えられます。 パッケージの場合、BPF プログラムはパッケージのデータとメタデータにアクセスできます (プログラムの種類に応じて、読み取りおよび書き込みのため)。カーネル関数を実行する場合は、次の引数にアクセスできます。カーネルメモリへのポインタなどを含む関数。

このプロセスを詳しく見てみましょう。 まず、プログラムがアセンブラーで書かれた古典的な BPF との最初の違いについて話しましょう。 新しいバージョンでは、プログラムを高級言語、主に C で記述できるようにアーキテクチャが拡張されました。このために、BPF アーキテクチャのバイトコードを生成できる llvm のバックエンドが開発されました。

BPF アーキテクチャは、部分的には最新のマシンで効率的に実行できるように設計されています。 これを実際に機能させるには、カーネルにロードされた BPF バイトコードが、JIT コンパイラーと呼ばれるコンポーネントを使用してネイティブ コードに変換されます (Just In T私）。 次に、覚えていると思いますが、従来の BPF では、プログラムはカーネルにロードされ、単一のシステム コールのコンテキストでアトミックにイベント ソースにアタッチされました。 新しいアーキテクチャでは、これは XNUMX 段階で行われます。最初に、システム コールを使用してコードがカーネルにロードされます。 bpf(2)その後、プログラムの種類に応じて異なる他のメカニズムを通じて、プログラムはイベント ソースに接続されます。

ここで読者は疑問を持つかもしれません：それは可能でしょうか？ このようなコードの実行の安全性はどのように保証されるのでしょうか? 実行の安全性は、ベリファイアーと呼ばれる BPF プログラムをロードする段階によって保証されます (英語では、この段階はベリファイアーと呼ばれます。今後もこの英語の単語を使用します)。

Verifier は、プログラムがカーネルの通常の動作を中断しないことを保証する静的アナライザーです。 ちなみに、これは、プログラムがシステムの動作に干渉できないという意味ではありません。BPF プログラムは、種類に応じて、カーネル メモリのセクションの読み取りと再書き込み、関数の戻り値、トリム、追加、再書き込みが可能です。さらにネットワークパケットを転送することもできます。 Verifier は、BPF プログラムを実行してもカーネルがクラッシュしないこと、およびルールに従って書き込みアクセス権を持つプログラム (送信パケットのデータなど) がパケットの外部のカーネル メモリを上書きできないことを保証します。 BPF の他のすべてのコンポーネントについて理解した後、対応するセクションで Verifier についてもう少し詳しく説明します。

では、これまでに何を学んだのでしょうか? ユーザーは C でプログラムを作成し、システム コールを使用してそれをカーネルにロードします。 bpf(2)、検証者によってチェックされ、ネイティブ バイトコードに変換されます。 次に、同じユーザーまたは別のユーザーがプログラムをイベント ソースに接続し、実行を開始します。 ブートと接続を分離する必要がある理由はいくつかあります。 まず、ベリファイアの実行は比較的高価であり、同じプログラムを何度もダウンロードすることでコンピュータの時間を無駄にします。 第二に、プログラムがどのように接続されるかはその種類によって異なり、XNUMX 年前に開発された XNUMX つの「ユニバーサル」インターフェイスは新しい種類のプログラムには適さない可能性があります。 (現在ではアーキテクチャがより成熟してきていますが、このインターフェースをレベルで統一するという考えもあります) libbpf.)

注意深い読者は、まだ写真が完成していないことに気づくかもしれません。 実際、上記のすべてでは、BPF が従来の BPF と比較して状況を根本的に変える理由を説明できません。 適用範囲を大幅に拡大する XNUMX つの革新は、共有メモリとカーネル ヘルパー関数を使用する機能です。 BPF では、共有メモリは、いわゆるマップ、つまり特定の API を備えた共有データ構造を使用して実装されます。 おそらく、最初に登場したマップのタイプがハッシュ テーブルだったため、この名前が付けられたと思われます。 その後、配列、ローカル (CPU ごと) ハッシュ テーブルとローカル配列、検索ツリー、BPF プログラムへのポインターを含むマップなどが登場しました。 私たちにとって興味深いのは、BPF プログラムが呼び出し間で状態を保持し、それを他のプログラムやユーザー空間と共有する機能を備えていることです。

マップはシステム コールを使用してユーザー プロセスからアクセスされます。 bpf(2)、およびヘルパー関数を使用してカーネル内で実行されている BPF プログラムから。 さらに、ヘルパーはマップを操作するためだけでなく、他のカーネル機能にアクセスするためにも存在します。 たとえば、BPF プログラムはヘルパー関数を使用して、パケットを他のインターフェイスに転送したり、perf イベントを生成したり、カーネル構造にアクセスしたりすることができます。

要約すると、BPF は、任意の、つまり検証者によってテストされたユーザー コードをカーネル空間にロードする機能を提供します。 このコードは、呼び出し間の状態を保存し、ユーザー空間とデータを交換することができ、また、このタイプのプログラムで許可されているカーネル サブシステムにアクセスすることもできます。

これはすでにカーネル モジュールによって提供される機能と似ていますが、BPF と比較すると、BPF にはいくつかの利点があります (もちろん、比較できるのは類似したアプリケーション (システム トレースなど) のみです。BPF で任意のドライバーを作成することはできません)。 エントリのしきい値が低いこと (BPF を使用する一部のユーティリティでは、ユーザーがカーネル プログラミング スキルや一般的なプログラミング スキルを必要としない)、実行時の安全性 (作成時にシステムを壊していない人はコメントで手を挙げてください) に注目してください。またはテストモジュール)、アトミック性 - モジュールをリロードするときにダウンタイムが発生し、BPF サブシステムはイベントが見逃されないことを保証します (公平を期すために、これはすべての種類の BPF プログラムに当てはまるわけではありません)。

このような機能の存在により、BPF はカーネルを拡張するための汎用ツールとなり、これは実際に確認されています。BPF にはますます新しいタイプのプログラムが追加され、戦闘サーバーで 24 時間 7 日 BPF を使用する大企業がますます増えています。スタートアップは、BPF に基づいたソリューションに基づいてビジネスを構築します。 BPF は、DDoS 攻撃からの保護、SDN の作成 (Kubernetes のネットワークの実装など)、メインのシステム トレース ツールおよび統計コレクターとして、侵入検知システムやサンドボックス システムなど、あらゆる場所で使用されています。

ここで記事の概要部分を終了し、仮想マシンと BPF エコシステムをさらに詳しく見てみましょう。

余談: 公共事業

次のセクションの例を実行できるようにするには、少なくともいくつかのユーティリティが必要になる場合があります。 llvm/clang BPF サポートと bpftool。 セクション内 開発ツール ユーティリティとカーネルを組み立てる手順を読むことができます。 このセクションは、プレゼンテーションの調和を乱さないように、以下に配置されています。

BPF 仮想マシンのレジスタと命令システム

BPF のアーキテクチャとコマンド システムは、プログラムが C 言語で記述され、カーネルにロードされた後にネイティブ コードに変換されるという事実を考慮して開発されました。 したがって、レジスタの数とコマンドのセットは、現代のマシンの機能の数学的な意味での共通点を考慮して選択されました。 さらに、プログラムにはさまざまな制限が課されており、たとえば、最近までループやサブルーチンを作成できなかったり、命令数が 4096 に制限されていました (現在、特権プログラムは最大 XNUMX 万命令を読み込むことができます)。

BPF にはユーザーがアクセスできる 64 ビット レジスタが XNUMX 個あります r0 - r10 そしてプログラムカウンター。 登録する r10 フレーム ポインターが含まれており、読み取り専用です。 プログラムは、実行時に 512 バイトのスタックと、マップの形式で無制限の共有メモリにアクセスできます。

BPF プログラムでは、プログラム タイプのカーネル ヘルパーの特定のセット、および最近では通常の関数を実行できます。 呼び出される各関数は、レジスタで渡される最大 XNUMX つの引数を取ることができます r1 - r5、戻り値はに渡されます r0。 関数から戻った後、レジスタの内容が更新されることが保証されます。 r6 - r9 変更されません。

プログラムを効率的に変換するには、レジスタを使用します。 r0 - r11 サポートされているすべてのアーキテクチャでは、現在のアーキテクチャの ABI 機能を考慮して、実レジスタに一意にマッピングされます。 たとえば、 x86_64 レジスター r1 - r5は、関数パラメータを渡すために使用され、 rdi, rsi, rdx, rcx, r8、パラメータを関数に渡すために使用されます。 x86_64。 たとえば、左側のコードは次のように右側のコードに変換されます。

1:  (b7) r1 = 1                    mov    $0x1,%rdi
2:  (b7) r2 = 2                    mov    $0x2,%rsi
3:  (b7) r3 = 3                    mov    $0x3,%rdx
4:  (b7) r4 = 4                    mov    $0x4,%rcx
5:  (b7) r5 = 5                    mov    $0x5,%r8
6:  (85) call pc+1                 callq  0x0000000000001ee8

レジスタ r0 プログラムの実行結果を返すためにも使用され、レジスター内で r1 プログラムにはコンテキストへのポインターが渡されます。プログラムの種類に応じて、これは構造体などになります。 struct xdp_md (XDP の場合) または構造体 struct __sk_buff (さまざまなネットワーク プログラム用) または構造 struct pt_regs (さまざまな種類のトレース プログラム用) など。

したがって、レジスタ、カーネル ヘルパー、スタック、コンテキスト ポインター、およびマップ形式の共有メモリのセットが存在しました。 旅行にこれらすべてが絶対に必要というわけではありませんが、...

説明を続けて、これらのオブジェクトを操作するためのコマンド システムについて話しましょう。 全て （ほとんどすべて) BPF 命令のサイズは 64 ビットに固定されています。 64 ビット ビッグ エンディアン マシン上の XNUMX つの命令を見ると、次のようになります。

それは Code - これは命令のエンコーディングです。 Dst/Src はそれぞれ受信側と送信側のエンコーディングです。 Off - 16 ビットの符号付きインデント、および Imm 一部の命令で使用される 32 ビットの符号付き整数です (cBPF 定数 K と同様)。 エンコーディング Code 次の XNUMX つのタイプのいずれかがあります。

命令クラス 0、1、2、3 は、メモリを操作するためのコマンドを定義します。 彼らは と呼ばれる, BPF_LD, BPF_LDX, BPF_ST, BPF_STX、 それぞれ。 クラス 4、7 (BPF_ALU, BPF_ALU64) は ALU 命令のセットを構成します。 クラス 5、6 (BPF_JMP, BPF_JMP32) にはジャンプ命令が含まれています。

BPF 命令システムを研究するためのさらなる計画は次のとおりです。すべての命令とそのパラメータを注意深くリストする代わりに、このセクションではいくつかの例を見ていき、そこから命令が実際にどのように機能するのか、そしてどのように実行するのかが明らかになります。 BPF 用のバイナリ ファイルを手動で逆アセンブルします。 記事の後半で内容を統合するために、Verifier、JIT コンパイラ、クラシック BPF の変換に関するセクション、およびマップの学習や関数の呼び出しなどに関する個別の手順についても説明します。

個々の命令について話すときは、コア ファイルを参照します。 bpf.h и bpf_common.h、BPF 命令の数値コードを定義します。 アーキテクチャを自分で勉強したり、バイナリを解析したりする場合は、複雑さの順に並べられた次のソースでセマンティクスを見つけることができます。 非公式の eBPF 仕様, BPF および XDP リファレンス ガイド、命令セット, ドキュメント/ネットワーク/filter.txt そしてもちろん、Linux ソース コード - ベリファイア、JIT、BPF インタプリタ。

例: 頭の中で BPF を分解する

プログラムをコンパイルする例を見てみましょう readelf-example.c 結果のバイナリを見てください。 オリジナルコンテンツを公開します readelf-example.c 以下は、バイナリ コードからロジックを復元した後です。

$ clang -target bpf -c readelf-example.c -o readelf-example.o -O2
$ llvm-readelf -x .text readelf-example.o
Hex dump of section '.text':
0x00000000 b7000000 01000000 15010100 00000000 ................
0x00000010 b7000000 02000000 95000000 00000000 ................

出力の最初の列 readelf はインデントなので、プログラムは XNUMX つのコマンドで構成されます。

Code Dst Src Off  Imm
b7   0   0   0000 01000000
15   0   1   0100 00000000
b7   0   0   0000 02000000
95   0   0   0000 00000000

コマンドコードが等しい b7, 15, b7 и 95。 最下位 7 ビットが命令クラスであることを思い出してください。 この例では、すべての命令の 5 番目のビットが空であるため、命令クラスはそれぞれ 7、5、7、XNUMX になります。クラス XNUMX は BPF_ALU64、5は BPF_JMP。 どちらのクラスでも、命令形式は同じであり (上記を参照)、次のようにプログラムを書き直すことができます (同時に、残りの列を人間の形式で書き換えます)。

Op S  Class   Dst Src Off  Imm
b  0  ALU64   0   0   0    1
1  0  JMP     0   1   1    0
b  0  ALU64   0   0   0    2
9  0  JMP     0   0   0    0

操作 b クラス ALU64 - です BPF_MOV。 宛先レジスタに値を割り当てます。 ビットがセットされている場合 s (ソース) の場合、値はソース レジスタから取得され、この場合のように設定されていない場合は、値はフィールドから取得されます。 Imm。 したがって、最初と XNUMX 番目の命令では次の操作を実行します。 r0 = Imm。 なお、JMP クラス 1 の動作は、 BPF_JEQ (等しい場合はジャンプ)。 私たちの場合、ビット以来、 S がゼロの場合、ソースレジスタの値とフィールドを比較します。 Imm。 値が一致すると、次への遷移が発生します。 PC + Offどこ PC通常どおり、次の命令のアドレスが含まれます。 最後に、JMP クラス 9 の動作は、 BPF_EXIT。 この命令はプログラムを終了し、カーネルに戻ります。 r0。 テーブルに新しい列を追加しましょう。

Op    S  Class   Dst Src Off  Imm    Disassm
MOV   0  ALU64   0   0   0    1      r0 = 1
JEQ   0  JMP     0   1   1    0      if (r1 == 0) goto pc+1
MOV   0  ALU64   0   0   0    2      r0 = 2
EXIT  0  JMP     0   0   0    0      exit

これをより便利な形式に書き直すことができます。

     r0 = 1
     if (r1 == 0) goto END
     r0 = 2
END:
     exit

レジスターに記載されている内容を覚えている場合 r1 プログラムにはカーネルからコンテキストへのポインタが渡され、レジスタに格納されます。 r0 値がカーネルに返されると、コンテキストへのポインタが 1 の場合は 2 を返し、それ以外の場合は XNUMX を返すことがわかります。ソースを見て、正しいことを確認してみましょう。

$ cat readelf-example.c
int foo(void *ctx)
{
        return ctx ? 2 : 1;
}

はい、これは無意味なプログラムですが、たった XNUMX つの単純な命令に変換されます。

例外例：16バイト命令

一部の命令は 64 ビット以上を占有すると前述しました。 これは、たとえば指示に当てはまります。 lddw (コード = 0x18 = BPF_LD | BPF_DW | BPF_IMM) - ダブルワードをフィールドからレジスタにロードします Imm。 ポイントは、ということです Imm のサイズは 32 で、ダブルワードは 64 ビットであるため、64 つの 64 ビット命令で 64 ビットの即値をレジスタにロードすることは機能しません。 これを行うには、XNUMX つの隣接する命令を使用して、XNUMX ビット値の XNUMX 番目の部分をフィールドに格納します。 Imm。 例：

$ cat x64.c
long foo(void *ctx)
{
        return 0x11223344aabbccdd;
}
$ clang -target bpf -c x64.c -o x64.o -O2
$ llvm-readelf -x .text x64.o
Hex dump of section '.text':
0x00000000 18000000 ddccbbaa 00000000 44332211 ............D3".
0x00000010 95000000 00000000                   ........

バイナリ プログラムには命令が XNUMX つだけあります。

Binary                                 Disassm
18000000 ddccbbaa 00000000 44332211    r0 = Imm[0]|Imm[1]
95000000 00000000                      exit

指示を持ってまた会いましょう lddw、移転とマップの操作について話すとき。

例: 標準ツールを使用した BPF の分解

したがって、BPF バイナリ コードを読み取る方法を学習し、必要に応じて命令を解析する準備ができました。 ただし、実際には、次のような標準ツールを使用してプログラムを逆アセンブルする方が便利で高速であることは言うまでもありません。

$ llvm-objdump -d x64.o

Disassembly of section .text:

0000000000000000 <foo>:
 0: 18 00 00 00 dd cc bb aa 00 00 00 00 44 33 22 11 r0 = 1234605617868164317 ll
 2: 95 00 00 00 00 00 00 00 exit

BPF オブジェクトのライフサイクル、bpffs ファイル システム

(このサブセクションで説明されている詳細の一部を初めて知りました。 断食 アレクセイ・スタロヴォイトフ BPF ブログ.)

BPF オブジェクト (プログラムとマップ) は、コマンドを使用してユーザー空間から作成されます BPF_PROG_LOAD и BPF_MAP_CREATE システムコール bpf(2)、これがどのように起こるかについては、次のセクションで詳しく説明します。 これにより、カーネル データ構造が作成され、それぞれに対して refcount (参照カウント) が XNUMX に設定され、オブジェクトを指すファイル記述子がユーザーに返されます。 ハンドルを閉めた後 refcount オブジェクトは XNUMX つ減り、ゼロになるとオブジェクトは破壊されます。

プログラムがマップを使用する場合、 refcount これらのマップは、プログラムのロード後に XNUMX つずつ増加します。 ファイル記述子はユーザープロセスから閉じることができますが、 refcount ゼロにはなりません:

プログラムが正常にロードされた後、通常、それを何らかのイベント ジェネレーターにアタッチします。 たとえば、受信パケットを処理したり、ネットワーク インターフェイスに接続したりすることができます。 tracepoint 核心にある。 この時点で、参照カウンタも XNUMX つ増加し、ローダー プログラムでファイル記述子を閉じることができるようになります。

ここでブートローダーをシャットダウンするとどうなるでしょうか? イベントジェネレータ（フック）の種類によって異なります。 すべてのネットワーク フックはローダーの完了後に存在します。これらはいわゆるグローバル フックです。 そして、たとえば、トレース プログラムは、それを作成したプロセスが終了した後に解放されます (したがって、「プロセスに対してローカル」という意味でローカルと呼ばれます)。 技術的には、ローカル フックは常にユーザー空間に対応するファイル記述子を持っているため、プロセスが閉じられると閉じられますが、グローバル フックはそうではありません。 次の図では、赤い十字を使用して、ローダー プログラムの終了がローカル フックとグローバル フックの場合のオブジェクトの存続期間にどのような影響を与えるかを示しています。

ローカルフックとグローバルフックに違いがあるのはなぜですか? 一部の種類のネットワーク プログラムの実行は、ユーザースペースなしでも意味があります。たとえば、DDoS 保護を想像してください。ブートローダーがルールを作成し、BPF プログラムをネットワーク インターフェイスに接続し、その後ブートローダーが自らを終了させることができます。 一方、膝の上で XNUMX 分かけて書いたデバッグ トレース プログラムを想像してください。それが完了したら、システムにゴミが残らないようにしたいと考えますが、ローカル フックがそれを保証します。

一方、カーネル内のトレースポイントに接続して、長年にわたる統計を収集したいと想像してください。 この場合、ユーザー部分を完了し、時々統計に戻ることが必要になります。 bpf ファイル システムはこの機会を提供します。 これは、BPF オブジェクトを参照するファイルの作成を可能にする、メモリ内専用の疑似ファイル システムです。 refcount オブジェクト。 この後、ローダーは終了でき、ローダーが作成したオブジェクトは生きたままになります。

BPF オブジェクトを参照する bpffs でのファイルの作成は、「ピン留め」と呼ばれます (次のフレーズのように、「プロセスは BPF プログラムまたはマップをピン留めできます」)。 BPF オブジェクトのファイル オブジェクトを作成することは、ローカル オブジェクトの寿命を延ばすだけでなく、グローバル オブジェクトの使いやすさにも意味があります。グローバル DDoS 保護プログラムの例に戻り、統計を確認できるようにしたいと考えています。時々。

BPF ファイル システムは通常、次の場所にマウントされます。 /sys/fs/bpfですが、たとえば次のようにローカルにマウントすることもできます。

$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

ファイルシステム名はコマンドを使用して作成されます。 BPF_OBJ_PIN BPF システムコール。 説明のために、プログラムを取得し、コンパイルし、アップロードして、次の場所に固定してみましょう。 bpffs。 私たちのプログラムは何も役に立ちません。例を再現できるようにコードを提示しているだけです。

$ cat test.c
__attribute__((section("xdp"), used))
int test(void *ctx)
{
        return 0;
}

char _license[] __attribute__((section("license"), used)) = "GPL";

このプログラムをコンパイルして、ファイル システムのローカル コピーを作成しましょう bpffs:

$ clang -target bpf -c test.c -o test.o
$ mkdir bpf-mountpoint
$ sudo mount -t bpf none bpf-mountpoint

次に、ユーティリティを使用してプログラムをダウンロードしましょう bpftool 付随するシステムコールを見てください。 bpf(2) (一部の無関係な行が strace 出力から削除されました):

$ sudo strace -e bpf bpftool prog load ./test.o bpf-mountpoint/test
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="test", ...}, 120) = 3
bpf(BPF_OBJ_PIN, {pathname="bpf-mountpoint/test", bpf_fd=3}, 120) = 0

ここでは、次を使用してプログラムをロードしました BPF_PROG_LOAD、カーネルからファイル記述子を受け取りました 3 そしてコマンドを使用して BPF_OBJ_PIN このファイル記述子をファイルとして固定しました "bpf-mountpoint/test"。 この後、ブートローダープログラム bpftool 動作は終了しましたが、プログラムはネットワーク インターフェイスに接続していなかったにもかかわらず、カーネル内に残りました。

$ sudo bpftool prog | tail -3
783: xdp  name test  tag 5c8ba0cf164cb46c  gpl
        loaded_at 2020-05-05T13:27:08+0000  uid 0
        xlated 24B  jited 41B  memlock 4096B

ファイルオブジェクトは普通に削除できます unlink(2) その後、対応するプログラムが削除されます。

$ sudo rm ./bpf-mountpoint/test
$ sudo bpftool prog show id 783
Error: get by id (783): No such file or directory

オブジェクトの削除

オブジェクトの削除について言えば、フック (イベント ジェネレーター) からプログラムを切断した後は、単一の新しいイベントがその起動をトリガーすることはありませんが、プログラムの現在のインスタンスはすべて通常の順序で完了することを明確にする必要があります。 。

一部の種類の BPF プログラムでは、その場でプログラムを置き換えることができます。 シーケンスの原子性を提供する replace = detach old program, attach new program。 この場合、古いバージョンのプログラムのすべてのアクティブなインスタンスが作業を終了し、新しいイベント ハンドラーが新しいプログラムから作成されます。ここでの「アトミック性」とは、単一のイベントが失われないことを意味します。

イベントソースへのプログラムの接続

この記事では、プログラムをイベント ソースに接続する方法については個別に説明しません。これは、特定の種類のプログラムのコンテキストで検討することが合理的であるためです。 Cm。 例 以下では、XDP などのプログラムがどのように接続されているかを示します。

bpf システムコールを使用したオブジェクトの操作

BPFプログラム

すべての BPF オブジェクトは、システム コールを使用してユーザー空間から作成および管理されます。 bpf、次のプロトタイプがあります。

#include <linux/bpf.h>

int bpf(int cmd, union bpf_attr *attr, unsigned int size);

こちらがチームです cmd type の値の XNUMX つです enum bpf_cmd, attr — 特定のプログラムのパラメータへのポインタ、および size — ポインタに応じたオブジェクトのサイズ、つまり通常はこれ sizeof(*attr)。 カーネル 5.8 では、システム コール bpf 34 の異なるコマンドをサポートし、 決定 union bpf_attr 200行を占めます。 ただし、数回の記事を読むうちにコマンドとパラメータについては慣れてくるので、これに怯える必要はありません。

チームから始めましょう BPF_PROG_LOAD、BPF プログラムを作成します - BPF 命令のセットを受け取り、それをカーネルにロードします。 ロード時にベリファイアが起動され、次に JIT コンパイラが起動され、実行が成功するとプログラム ファイル記述子がユーザーに返されます。 前のセクションで次に彼に何が起こるかを見ました BPF オブジェクトのライフサイクルについて.

ここで、単純な BPF プログラムをロードするカスタム プログラムを作成しますが、最初にロードするプログラムの種類を決定する必要があります。 тип そして、このタイプのフレームワーク内で、検証者テストに合格するプログラムを作成します。 ただし、プロセスを複雑にしないために、既製のソリューションを次に示します。次のようなプログラムを使用します。 BPF_PROG_TYPE_XDP、値を返します XDP_PASS (すべてのパッケージをスキップします)。 BPF アセンブラでは、非常に単純に見えます。

r0 = 2
exit

決定した後 その アップロードしますので、その方法をお伝えします。

#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

static inline __u64 ptr_to_u64(const void *ptr)
{
        return (__u64) (unsigned long) ptr;
}

int main(void)
{
    struct bpf_insn insns[] = {
        {
            .code = BPF_ALU64 | BPF_MOV | BPF_K,
            .dst_reg = BPF_REG_0,
            .imm = XDP_PASS
        },
        {
            .code = BPF_JMP | BPF_EXIT
        },
    };

    union bpf_attr attr = {
        .prog_type = BPF_PROG_TYPE_XDP,
        .insns     = ptr_to_u64(insns),
        .insn_cnt  = sizeof(insns)/sizeof(insns[0]),
        .license   = ptr_to_u64("GPL"),
    };

    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

プログラム内の興味深いイベントは配列の定義から始まります insns - マシンコードの BPF プログラム。 この場合、BPF プログラムの各命令は構造体にパックされます。 bpf_insn。 最初の要素 insns 指示に従っている r0 = 2、 XNUMX番目 - exit.

退却。 カーネルは、マシンコードを記述したり、カーネルヘッダーファイルを使用したりするための、より便利なマクロを定義します。 tools/include/linux/filter.h 私たちは書くことができます

struct bpf_insn insns[] = {
    BPF_MOV64_IMM(BPF_REG_0, XDP_PASS),
    BPF_EXIT_INSN()
};

ただし、ネイティブ コードで BPF プログラムを作成する必要があるのは、カーネルでのテストや BPF に関する記事を作成する場合のみであるため、これらのマクロがなくても開発者の作業がそれほど複雑になることはありません。

BPF プログラムを定義したら、カーネルへのロードに進みます。 最小限のパラメータセット attr プログラムの種類、命令のセットと数、必要なライセンス、名前が含まれます。 "woo"、ダウンロード後にシステム上でプログラムを見つけるために使用します。 プログラムは、約束どおり、システム コールを使用してシステムにロードされます。 bpf.

プログラムの最後では、ペイロードをシミュレートする無限ループに陥ります。 これがないと、システムコールから返されたファイル記述子が閉じられると、プログラムはカーネルによって強制終了されます。 bpf、システムには表示されません。

さて、テストの準備が整いました。 以下のプログラムをアセンブルして実行してみましょう straceすべてが正常に動作していることを確認するには、次のようにします。

$ clang -g -O2 simple-prog.c -o simple-prog

$ sudo strace ./simple-prog
execve("./simple-prog", ["./simple-prog"], 0x7ffc7b553480 /* 13 vars */) = 0
...
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0x7ffe03c4ed50, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_V
ERSION(0, 0, 0), prog_flags=0, prog_name="woo", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS}, 72) = 3
pause(

すべて順調、 bpf(2) ハンドル 3 が返され、無限ループに入りました。 pause()。 システム内でプログラムを見つけてみましょう。 これを行うには、別のターミナルに移動してユーティリティを使用します。 bpftool:

# bpftool prog | grep -A3 woo
390: xdp  name woo  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-31T24:66:44+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        pids simple-prog(10381)

システムにロードされたプログラムがあることがわかります woo グローバル ID は 390 で、現在進行中です simple-prog プログラムを指す開いているファイル記述子がある (そして、 simple-prog 仕事は終わります、それから woo 消えるだろう）。 予想通り、このプログラムは、 woo BPF アーキテクチャでは 16 バイト (86 命令) のバイナリ コードを必要としますが、ネイティブ形式 (x64_40) ではすでに XNUMX バイトです。 プログラムを元の形式で見てみましょう。

# bpftool prog dump xlated id 390
   0: (b7) r0 = 2
   1: (95) exit

驚く様な事じゃない。 次に、JIT コンパイラーによって生成されたコードを見てみましょう。

# bpftool prog dump jited id 390
bpf_prog_3b185187f1855c4c_woo:
   0:   nopl   0x0(%rax,%rax,1)
   5:   push   %rbp
   6:   mov    %rsp,%rbp
   9:   sub    $0x0,%rsp
  10:   push   %rbx
  11:   push   %r13
  13:   push   %r14
  15:   push   %r15
  17:   pushq  $0x0
  19:   mov    $0x2,%eax
  1e:   pop    %rbx
  1f:   pop    %r15
  21:   pop    %r14
  23:   pop    %r13
  25:   pop    %rbx
  26:   leaveq
  27:   retq

～にはあまり効果的ではない exit(2)ただし、公平を期すために言うと、私たちのプログラムは単純すぎるため、自明ではないプログラムの場合は、JIT コンパイラーによって追加されるプロローグとエピローグが当然必要になります。

ゲレンデマップ

BPF プログラムは、他の BPF プログラムとユーザー空間のプログラムの両方にアクセスできる構造化メモリ領域を使用できます。 これらのオブジェクトはマップと呼ばれ、このセクションではシステム コールを使用してそれらを操作する方法を示します。 bpf.

マップの機能は共有メモリへのアクセスだけに限定されないことをすぐに言ってみましょう。 たとえば、BPF プログラムへのポインタやネットワーク インターフェイスへのポインタ、perf イベントを操作するためのマップなどを含む特殊な目的のマップがあります。 読者を混乱させないように、ここではそれらについては触れません。 これとは別に、同期の問題はこの例では重要ではないため、無視します。 利用可能なマップ タイプの完全なリストは、次の場所にあります。 <linux/bpf.h>このセクションでは、歴史上最初のタイプであるハッシュ テーブルを例として取り上げます。 BPF_MAP_TYPE_HASH.

たとえば C++ でハッシュ テーブルを作成する場合は、次のようになります。 unordered_map<int,long> woo、ロシア語で「テーブルが必要です」という意味です woo サイズは無制限、キーのタイプは次のとおりです int、値は型です long」 BPF ハッシュ テーブルを作成するには、テーブルの最大サイズを指定する必要があることと、キーと値のタイプを指定する代わりに、それらのサイズをバイト単位で指定する必要がある点を除いて、ほぼ同じことを行う必要があります。 。 マップを作成するには、次のコマンドを使用します BPF_MAP_CREATE システムコール bpf。 地図を作成するほぼ最小限のプログラムを見てみましょう。 BPF プログラムをロードする前のプログラムの後では、このプログラムは簡単に見えるはずです。

$ cat simple-map.c
#define _GNU_SOURCE
#include <string.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <linux/bpf.h>

int main(void)
{
    union bpf_attr attr = {
        .map_type = BPF_MAP_TYPE_HASH,
        .key_size = sizeof(int),
        .value_size = sizeof(int),
        .max_entries = 4,
    };
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));

    for ( ;; )
        pause();
}

ここでパラメータのセットを定義します attrここでは、「キーとサイズ値を含むハッシュ テーブルが必要です」と言います。 sizeof(int)、最大 XNUMX つの要素を入れることができます。」 BPF マップを作成するときは、他のパラメーターを指定できます。たとえば、プログラムの例と同じ方法で、オブジェクトの名前を次のように指定しました。 "woo".

プログラムをコンパイルして実行してみましょう。

$ clang -g -O2 simple-map.c -o simple-map
$ sudo strace ./simple-map
execve("./simple-map", ["./simple-map"], 0x7ffd40a27070 /* 14 vars */) = 0
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_HASH, key_size=4, value_size=4, max_entries=4, map_name="woo", ...}, 72) = 3
pause(

システムコールはこちら bpf(2) 記述子マップ番号を返しました 3 その後、プログラムは予想どおり、システム コールでのさらなる命令を待ちます。 pause(2).

次に、プログラムをバックグラウンドに送信するか、別のターミナルを開いて、ユーティリティを使用してオブジェクトを見てみましょう bpftool (マップを名前で他のマップと区別できます):

$ sudo bpftool map
...
114: hash  name woo  flags 0x0
        key 4B  value 4B  max_entries 4  memlock 4096B
...

数字 114 はオブジェクトのグローバル ID です。 システム上のすべてのプログラムは、この ID を使用して、次のコマンドを使用して既存のマップを開くことができます。 BPF_MAP_GET_FD_BY_ID システムコール bpf.

これで、ハッシュ テーブルを使って遊ぶことができます。 その内容を見てみましょう。

$ sudo bpftool map dump id 114
Found 0 elements

空の。 値を入れてみましょう hash[1] = 1:

$ sudo bpftool map update id 114 key 1 0 0 0 value 1 0 0 0

もう一度表を見てみましょう。

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
Found 1 element

万歳！ 要素を XNUMX つ追加することができました。 これを行うにはバイトレベルで作業する必要があることに注意してください。 bptftool ハッシュテーブルの値がどのような型であるかはわかりません。 (この知識は BTF を使用して彼女に転送できますが、それについては今すぐ説明します。)

bpftool は要素をどのように正確に読み取り、追加しますか? 内部を見てみましょう:

$ sudo strace -e bpf bpftool map dump id 114
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=NULL, next_key=0x55856ab65280}, 120) = 0
bpf(BPF_MAP_LOOKUP_ELEM, {map_fd=3, key=0x55856ab65280, value=0x55856ab652a0}, 120) = 0
key: 01 00 00 00  value: 01 00 00 00
bpf(BPF_MAP_GET_NEXT_KEY, {map_fd=3, key=0x55856ab65280, next_key=0x55856ab65280}, 120) = -1 ENOENT

まず、コマンドを使用してグローバル ID でマップを開きました。 BPF_MAP_GET_FD_BY_ID и bpf(2) 記述子 3 が返されました。さらにコマンドを使用します。 BPF_MAP_GET_NEXT_KEY を渡すことでテーブル内の最初のキーを見つけました。 NULL 「前」キーへのポインタとして。 鍵があればできること BPF_MAP_LOOKUP_ELEMポインタに値を返す value。 次のステップでは、現在のキーへのポインターを渡して次の要素を見つけようとしますが、テーブルには XNUMX つの要素とコマンドのみが含まれています。 BPF_MAP_GET_NEXT_KEY 戻る ENOENT.

さて、キー 1 で値を変更しましょう。ビジネス ロジックで登録が必要だとします。 hash[1] = 2:

$ sudo strace -e bpf bpftool map update id 114 key 1 0 0 0 value 2 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x55dcd72be260, value=0x55dcd72be280, flags=BPF_ANY}, 120) = 0

予想どおり、それは非常に簡単です: コマンド BPF_MAP_GET_FD_BY_ID ID とコマンドでマップを開きます BPF_MAP_UPDATE_ELEM 要素を上書きします。

したがって、あるプログラムからハッシュ テーブルを作成した後、別のプログラムからその内容を読み書きすることができます。 コマンドラインからこれを実行できた場合は、システム上の他のプログラムでも実行できることに注意してください。 上で説明したコマンドに加えて、ユーザー空間からマップを操作するには、 以下:

• BPF_MAP_LOOKUP_ELEM: キーによる値の検索
• BPF_MAP_UPDATE_ELEM: 値の更新/作成
• BPF_MAP_DELETE_ELEM: キーを削除します
• BPF_MAP_GET_NEXT_KEY: 次の (または最初の) キーを検索します。
• BPF_MAP_GET_NEXT_ID: 既存のすべてのマップを通過できます。それが仕組みです bpftool map
• BPF_MAP_GET_FD_BY_ID: グローバル ID で既存のマップを開きます
• BPF_MAP_LOOKUP_AND_DELETE_ELEM: オブジェクトの値をアトミックに更新し、古い値を返します。
• BPF_MAP_FREEZE: マップをユーザー空間から不変にします (この操作は元に戻すことができません)
• BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH, BPF_MAP_DELETE_BATCH: 一括操作。 例えば、 BPF_MAP_LOOKUP_AND_DELETE_BATCH - これは、マップからすべての値を読み取り、リセットする唯一の信頼できる方法です

これらのコマンドのすべてがすべてのマップ タイプで機能するわけではありませんが、一般に、ユーザー空間から他のタイプのマップを操作することは、ハッシュ テーブルを操作することとまったく同じように見えます。

順序のために、ハッシュ テーブルの実験を終了しましょう。 最大 XNUMX つのキーを含めることができるテーブルを作成したことを覚えていますか? さらにいくつかの要素を追加してみましょう。

$ sudo bpftool map update id 114 key 2 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 3 0 0 0 value 1 0 0 0
$ sudo bpftool map update id 114 key 4 0 0 0 value 1 0 0 0

ここまでは順調ですね：

$ sudo bpftool map dump id 114
key: 01 00 00 00  value: 01 00 00 00
key: 02 00 00 00  value: 01 00 00 00
key: 04 00 00 00  value: 01 00 00 00
key: 03 00 00 00  value: 01 00 00 00
Found 4 elements

もう XNUMX つ追加してみましょう:

$ sudo bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
Error: update failed: Argument list too long

予想通り、成功しませんでした。 エラーを詳しく見てみましょう。

$ sudo strace -e bpf bpftool map update id 114 key 5 0 0 0 value 1 0 0 0
bpf(BPF_MAP_GET_FD_BY_ID, {map_id=114, next_id=0, open_flags=0}, 120) = 3
bpf(BPF_OBJ_GET_INFO_BY_FD, {info={bpf_fd=3, info_len=80, info=0x7ffe6c626da0}}, 120) = 0
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=3, key=0x56049ded5260, value=0x56049ded5280, flags=BPF_ANY}, 120) = -1 E2BIG (Argument list too long)
Error: update failed: Argument list too long
+++ exited with 255 +++

すべて順調です: 予想どおり、チーム BPF_MAP_UPDATE_ELEM 新しい XNUMX 番目のキーを作成しようとしますが、クラッシュします E2BIG.

したがって、BPF プログラムを作成してロードできるだけでなく、ユーザー空間からマップを作成および管理することもできます。 ここで、BPF プログラム自体のマップをどのように使用できるかを検討するのは当然です。 これについては、マシン マクロ コードの読みにくいプログラムの言語で話すこともできますが、実際には、BPF プログラムが実際にどのように記述され、維持されるかを示す時期が来ています。 libbpf.

(低レベルのサンプルがないことに不満のある読者のために: を使用して作成されたマップとヘルパー関数を使用するプログラムを詳細に分析します) libbpf そして指導レベルで何が起こるかを教えてください。 不満のある読者へ とても、追加しました 例 記事内の適切な場所に記載してください。)

libbpf を使用した BPF プログラムの作成

マシンコードを使用して BPF プログラムを作成するのは最初だけで、その後は飽きが来ます。 この瞬間、あなたが注意を向けるべきなのは、 llvm、BPF アーキテクチャのコードを生成するバックエンドとライブラリがあります。 libbpfこれにより、BPF アプリケーションのユーザー側を作成し、次を使用して生成された BPF プログラムのコードをロードできます。 llvm/clang.

実際、この記事とその後の記事で説明するように、 libbpf これなし (または同様のツール - iproute2, libbcc, libbpf-go、など）生きていくことは不可能です。 このプロジェクトのキラー機能の XNUMX つは libbpf BPF CO-RE (Compile Once, Run Everywhere) - あるカーネルから別のカーネルに移植可能で、さまざまな API (たとえば、カーネル構造がバージョンから変更された場合など) で実行できる BPF プログラムを作成できるプロジェクトです。バージョンに合わせて)。 CO-RE で動作できるようにするには、カーネルを BTF サポートを使用してコンパイルする必要があります (これを行う方法については、セクションで説明します) 開発ツール。 カーネルが BTF で構築されているかどうかは、次のファイルの存在によって非常に簡単に確認できます。

$ ls -lh /sys/kernel/btf/vmlinux
-r--r--r-- 1 root root 2.6M Jul 29 15:30 /sys/kernel/btf/vmlinux

このファイルには、カーネルで使用されるすべてのデータ型に関する情報が保存され、次を使用するすべての例で使用されます。 libbpf。 CO-RE については次の記事で詳しく説明しますが、この記事では、次のようなカーネルを自分で構築するだけです。 CONFIG_DEBUG_INFO_BTF.

図書館 libbpf ディレクトリ内に存在します tools/lib/bpf カーネルとその開発はメーリング リストを通じて行われます。 [email protected]。 ただし、カーネルの外部に存在するアプリケーションのニーズに備えて、別のリポジトリが維持されます。 https://github.com/libbpf/libbpf この場合、カーネル ライブラリは読み取りアクセス用にほぼそのままミラーリングされます。

このセクションでは、次を使用するプロジェクトを作成する方法を見ていきます。 libbpf、いくつかの (多かれ少なかれ意味のない) テスト プログラムを作成し、それがどのように機能するかを詳細に分析してみましょう。 これにより、次のセクションで、BPF プログラムがマップ、カーネル ヘルパー、BTF などとどのように対話するかを正確に説明することができます。

通常、次を使用してプロジェクトを実行します。 libbpf GitHub リポジトリを git サブモジュールとして追加するには、同じことを行います。

$ mkdir /tmp/libbpf-example
$ cd /tmp/libbpf-example/
$ git init-db
Initialized empty Git repository in /tmp/libbpf-example/.git/
$ git submodule add https://github.com/libbpf/libbpf.git
Cloning into '/tmp/libbpf-example/libbpf'...
remote: Enumerating objects: 200, done.
remote: Counting objects: 100% (200/200), done.
remote: Compressing objects: 100% (103/103), done.
remote: Total 3354 (delta 101), reused 118 (delta 79), pack-reused 3154
Receiving objects: 100% (3354/3354), 2.05 MiB | 10.22 MiB/s, done.
Resolving deltas: 100% (2176/2176), done.

に行く libbpf 非常にシンプル：

$ cd libbpf/src
$ mkdir build
$ OBJDIR=build DESTDIR=root make -s install
$ find root
root
root/usr
root/usr/include
root/usr/include/bpf
root/usr/include/bpf/bpf_tracing.h
root/usr/include/bpf/xsk.h
root/usr/include/bpf/libbpf_common.h
root/usr/include/bpf/bpf_endian.h
root/usr/include/bpf/bpf_helpers.h
root/usr/include/bpf/btf.h
root/usr/include/bpf/bpf_helper_defs.h
root/usr/include/bpf/bpf.h
root/usr/include/bpf/libbpf_util.h
root/usr/include/bpf/libbpf.h
root/usr/include/bpf/bpf_core_read.h
root/usr/lib64
root/usr/lib64/libbpf.so.0.1.0
root/usr/lib64/libbpf.so.0
root/usr/lib64/libbpf.a
root/usr/lib64/libbpf.so
root/usr/lib64/pkgconfig
root/usr/lib64/pkgconfig/libbpf.pc

このセクションの次の計画は次のとおりです。次のような BPF プログラムを作成します。 BPF_PROG_TYPE_XDP、前の例と同じですが、C では次のようにコンパイルします。 clangそして、それをカーネルにロードするヘルパー プログラムを作成します。 次のセクションでは、BPF プログラムとアシスタント プログラムの両方の機能を拡張します。

例: libbpf を使用した本格的なアプリケーションの作成

まず、ファイルを使用します /sys/kernel/btf/vmlinux、これは上で説明したもので、同等のものをヘッダー ファイルの形式で作成します。

$ bpftool btf dump file /sys/kernel/btf/vmlinux format c > vmlinux.h

このファイルには、カーネルで使用できるすべてのデータ構造が保存されます。たとえば、IPv4 ヘッダーがカーネルで定義される方法は次のとおりです。

$ grep -A 12 'struct iphdr {' vmlinux.h
struct iphdr {
    __u8 ihl: 4;
    __u8 version: 4;
    __u8 tos;
    __be16 tot_len;
    __be16 id;
    __be16 frag_off;
    __u8 ttl;
    __u8 protocol;
    __sum16 check;
    __be32 saddr;
    __be32 daddr;
};

ここで、BPF プログラムを C で作成します。

$ cat xdp-simple.bpf.c
#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
        return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

私たちのプログラムは非常に単純であることが判明しましたが、依然として多くの詳細に注意を払う必要があります。 まず、最初にインクルードするヘッダー ファイルは次のとおりです。 vmlinux.hを使用して生成したばかりです bpftool btf dump - カーネル構造がどのようなものかを知るために kernel-headers パッケージをインストールする必要はなくなりました。 次のヘッダー ファイルはライブラリから提供されます。 libbpf。 これで必要なのはマクロを定義するためだけです SEC、ELF オブジェクト ファイルの適切なセクションに文字を送信します。 私たちのプログラムはセクションに含まれています xdp/simpleここで、スラッシュの前にプログラム タイプ BPF を定義します。これは、 libbpf、セクション名に基づいて、起動時に正しい型に置き換えられます。 bpf(2)。 BPF プログラム自体は、 C - 非常にシンプルで XNUMX 行で構成されます return XDP_PASS。 最後に別セクションとして、 "license" ライセンスの名前が含まれます。

llvm/clang、バージョン >= 10.0.0、またはそれ以上を使用してプログラムをコンパイルできます (セクションを参照) 開発ツール):

$ clang --version
clang version 11.0.0 (https://github.com/llvm/llvm-project.git afc287e0abec710398465ee1f86237513f2b5091)
...

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o

興味深い機能としては、ターゲット アーキテクチャを示します。 -target bpf ヘッダーへのパス libbpf、最近インストールしました。 また、忘れないでください -O2, このオプションを使用しないと、将来驚くような事態に遭遇する可能性があります。 コードを見てみましょう。希望通りのプログラムを書くことができましたか?

$ llvm-objdump --section=xdp/simple --no-show-raw-insn -D xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       r0 = 2
       1:       exit

はい、うまくいきました！ これでプログラムを含むバイナリ ファイルができたので、それをカーネルにロードするアプリケーションを作成したいと思います。 この目的のために、図書館は libbpf には、低レベル API を使用するか、高レベル API を使用するかの XNUMX つのオプションがあります。 私たちは、その後の学習のために最小限の労力で BPF プログラムを作成、ロード、接続する方法を学びたいので、XNUMX 番目の方法に進みます。

まず、同じユーティリティを使用して、バイナリからプログラムの「スケルトン」を生成する必要があります。 bpftool — BPF 界のスイスナイフ (BPF の作成者および保守者の XNUMX 人であるダニエル・ボルクマンはスイス人なので、文字通りに受け取ることができます):

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h

ファイル内 xdp-simple.skel.h プログラムのバイナリ コードと、オブジェクトのロード、アタッチ、削除などを管理するための関数が含まれています。 この単純なケースでは、これはやりすぎのように見えますが、オブジェクト ファイルに多くの BPF プログラムとマップが含まれている場合でも機能し、この巨大な ELF をロードするには、スケルトンを生成し、カスタム アプリケーションから XNUMX つまたは XNUMX つの関数を呼び出すだけで済みます。書いています。さあ、先に進みましょう。

厳密に言えば、私たちのローダー プログラムは簡単です。

#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    pause();

    xdp_simple_bpf__destroy(obj);
}

それは struct xdp_simple_bpf ファイルで定義されている xdp-simple.skel.h そしてオブジェクト ファイルについて説明します。

struct xdp_simple_bpf {
    struct bpf_object_skeleton *skeleton;
    struct bpf_object *obj;
    struct {
        struct bpf_program *simple;
    } progs;
    struct {
        struct bpf_link *simple;
    } links;
};

ここで低レベル API の痕跡を見ることができます: 構造 struct bpf_program *simple и struct bpf_link *simple。 最初の構造は、セクションに書かれているプログラムを具体的に説明しています。 xdp/simpleXNUMX 番目の部分では、プログラムがイベント ソースにどのように接続するかを説明します。

機能 xdp_simple_bpf__open_and_load、ELF オブジェクトを開いて解析し、すべての構造とサブ構造 (プログラムの他に、ELF にはデータ、読み取り専用データ、デバッグ情報、ライセンスなどの他のセクションも含まれます) を作成し、システムを使用してそれをカーネルにロードします。電話 bpfこれは、プログラムをコンパイルして実行することで確認できます。

$ clang -O2 -I ./libbpf/src/root/usr/include/ xdp-simple.c -o xdp-simple ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_BTF_LOAD, 0x7ffdb8fd9670, 120)  = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=2, insns=0xdfd580, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_VERSION(5, 8, 0), prog_flags=0, prog_name="simple", prog_ifindex=0, expected_attach_type=0x25 /* BPF_??? */, ...}, 120) = 4

では、次を使用してプログラムを見てみましょう。 bpftool。 彼女の ID を見つけてみましょう:

# bpftool p | grep -A4 simple
463: xdp  name simple  tag 3b185187f1855c4c  gpl
        loaded_at 2020-08-01T01:59:49+0000  uid 0
        xlated 16B  jited 40B  memlock 4096B
        btf_id 185
        pids xdp-simple(16498)

および dump (コマンドの短縮形を使用します) bpftool prog dump xlated):

# bpftool p d x id 463
int simple(void *ctx):
; return XDP_PASS;
   0: (b7) r0 = 2
   1: (95) exit

新しい何か！ プログラムは C ソース ファイルのチャンクを出力しました。これはライブラリによって行われました。 libbpf、バイナリ内でデバッグ セクションを見つけ、それを BTF オブジェクトにコンパイルし、次を使用してカーネルにロードしました。 BPF_BTF_LOAD、そして、コマンドでプログラムをロードするときに、結果のファイル記述子を指定します。 BPG_PROG_LOAD.

カーネルヘルパー

BPF プログラムは、「外部」関数、つまりカーネル ヘルパーを実行できます。 これらのヘルパー関数により、BPF プログラムはカーネル構造にアクセスし、マップを管理し、パフォーマンス イベントの作成、ハードウェアの制御 (パケットのリダイレクトなど) などの「現実世界」との通信も行うことができます。

例: bpf_get_smp_processor_id

「例による学習」パラダイムの枠組みの中で、ヘルパー関数の XNUMX つを考えてみましょう。 bpf_get_smp_processor_id(), ある ファイル内 kernel/bpf/helpers.c。 これは、呼び出し元の BPF プログラムが実行されているプロセッサの番号を返します。 しかし、私たちはそのセマンティクスにはあまり興味がなく、実装が XNUMX 行で済むという事実に興味があります。

BPF_CALL_0(bpf_get_smp_processor_id)
{
    return smp_processor_id();
}

BPF ヘルパー関数の定義は、Linux システム コールの定義に似ています。 ここでは、たとえば、引数のない関数が定義されています。 (たとえば、XNUMX つの引数を取る関数は、マクロを使用して定義されます。 BPF_CALL_3。 引数の最大数は XNUMX です。) ただし、これは定義の最初の部分にすぎません。 XNUMX 番目の部分は型構造を定義することです struct bpf_func_protoこれには、検証者が理解できるヘルパー関数の説明が含まれています。

const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
    .func     = bpf_get_smp_processor_id,
    .gpl_only = false,
    .ret_type = RET_INTEGER,
};

ヘルパー関数の登録

特定のタイプの BPF プログラムがこの関数を使用するには、この関数を登録する必要があります。たとえば、次のタイプの BPF プログラムです。 BPF_PROG_TYPE_XDP 関数はカーネルで定義されています xdp_func_proto、ヘルパー関数 ID から、XDP がこの関数をサポートするかどうかを決定します。 私たちの役割は サポートする:

static const struct bpf_func_proto *
xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
    switch (func_id) {
    ...
    case BPF_FUNC_get_smp_processor_id:
        return &bpf_get_smp_processor_id_proto;
    ...
    }
}

新しい BPF プログラム タイプはファイル内で「定義」されます include/linux/bpf_types.h マクロを使用する BPF_PROG_TYPE。 これは論理的な定義であるため引用符で囲まれています。C 言語の用語では、具体的な構造のセット全体の定義は他の場所で行われます。 特にファイル内では、 kernel/bpf/verifier.c ファイルからのすべての定義 bpf_types.h 構造体の配列を作成するために使用されます bpf_verifier_ops[]:

static const struct bpf_verifier_ops *const bpf_verifier_ops[] = {
#define BPF_PROG_TYPE(_id, _name, prog_ctx_type, kern_ctx_type) 
    [_id] = & _name ## _verifier_ops,
#include <linux/bpf_types.h>
#undef BPF_PROG_TYPE
};

つまり、BPF プログラムのタイプごとに、そのタイプのデータ構造へのポインタが定義されます。 struct bpf_verifier_ops、値で初期化されます _name ## _verifier_ops、つまり、 xdp_verifier_ops のために xdp。 構造 xdp_verifier_ops によって決定 ファイル内 net/core/filter.c 次のようにします。

const struct bpf_verifier_ops xdp_verifier_ops = {
    .get_func_proto     = xdp_func_proto,
    .is_valid_access    = xdp_is_valid_access,
    .convert_ctx_access = xdp_convert_ctx_access,
    .gen_prologue       = bpf_noop_prologue,
};

ここではおなじみの関数を見てみましょう xdp_func_proto、チャレンジが発生するたびにベリファイアを実行します。 いくつか BPF プログラム内の関数については、を参照してください。 verifier.c.

仮説的な BPF プログラムがこの関数をどのように使用するかを見てみましょう。 bpf_get_smp_processor_id。 これを行うには、前のセクションのプログラムを次のように書き直します。

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

SEC("xdp/simple")
int simple(void *ctx)
{
    if (bpf_get_smp_processor_id() != 0)
        return XDP_DROP;
    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

シンボル bpf_get_smp_processor_id によって決定 в <bpf/bpf_helper_defs.h> ライブラリー libbpf 方法

static u32 (*bpf_get_smp_processor_id)(void) = (void *) 8;

あれは、 bpf_get_smp_processor_id 値が 8 である関数ポインタです。8 は値です。 BPF_FUNC_get_smp_processor_id типа enum bpf_fun_id、ファイル内で定義されています vmlinux.h （ファイル bpf_helper_defs.h カーネル内の数値はスクリプトによって生成されるため、「マジック」数値は問題ありません)。 この関数は引数をとらず、次の型の値を返します。 __u32。 プログラムで実行すると、 clang 命令を生成します BPF_CALL 「正しい種類」 プログラムをコンパイルしてセクションを見てみましょう xdp/simple:

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ llvm-objdump -D --section=xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       bf 01 00 00 00 00 00 00 r1 = r0
       2:       67 01 00 00 20 00 00 00 r1 <<= 32
       3:       77 01 00 00 20 00 00 00 r1 >>= 32
       4:       b7 00 00 00 02 00 00 00 r0 = 2
       5:       15 01 01 00 00 00 00 00 if r1 == 0 goto +1 <LBB0_2>
       6:       b7 00 00 00 01 00 00 00 r0 = 1

0000000000000038 <LBB0_2>:
       7:       95 00 00 00 00 00 00 00 exit

最初の行には指示が表示されます call、パラメータ IMM これは 8 に等しく、 SRC_REG - ゼロ。 検証者が使用する ABI 規約によれば、これはヘルパー関数 XNUMX 番への呼び出しです。 起動したら、ロジックは簡単です。 レジスタからの戻り値 r0 にコピーされました r1 2,3 行目で type に変換されます。 u32 — 上位 32 ビットがクリアされます。 4,5,6,7、2、XNUMX、XNUMX 行目では XNUMX (XDP_PASS) または 1 (XDP_DROP) 行 0 のヘルパー関数がゼロまたはゼロ以外の値を返したかどうかに応じて異なります。

自分自身をテストしてみましょう: プログラムをロードして出力を見てみましょう bpftool prog dump xlated:

$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple &
[2] 10914

$ sudo bpftool p | grep simple
523: xdp  name simple  tag 44c38a10c657e1b0  gpl
        pids xdp-simple(10915)

$ sudo bpftool p d x id 523
int simple(void *ctx):
; if (bpf_get_smp_processor_id() != 0)
   0: (85) call bpf_get_smp_processor_id#114128
   1: (bf) r1 = r0
   2: (67) r1 <<= 32
   3: (77) r1 >>= 32
   4: (b7) r0 = 2
; }
   5: (15) if r1 == 0x0 goto pc+1
   6: (b7) r0 = 1
   7: (95) exit

OK、検証者は正しいカーネルヘルパーを見つけました。

例: 引数を渡して、最後にプログラムを実行します。

すべての実行レベルのヘルパー関数にはプロトタイプがあります

u64 fn(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)

ヘルパー関数へのパラメータはレジスタで渡されます r1 - r5、値がレジスタに返されます r0。 XNUMX つを超える引数を取る関数はなく、それらのサポートは将来追加される予定はありません。

新しいカーネル ヘルパーと、BPF がパラメーターを渡す方法を見てみましょう。 書き直しましょう xdp-simple.bpf.c 以下のようになります (残りの行は変更されていません)。

SEC("xdp/simple")
int simple(void *ctx)
{
    bpf_printk("running on CPU%un", bpf_get_smp_processor_id());
    return XDP_PASS;
}

私たちのプログラムは、実行されている CPU の番号を出力します。 コンパイルしてコードを見てみましょう。

$ llvm-objdump -D --section=xdp/simple --no-show-raw-insn xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       r1 = 10
       1:       *(u16 *)(r10 - 8) = r1
       2:       r1 = 8441246879787806319 ll
       4:       *(u64 *)(r10 - 16) = r1
       5:       r1 = 2334956330918245746 ll
       7:       *(u64 *)(r10 - 24) = r1
       8:       call 8
       9:       r1 = r10
      10:       r1 += -24
      11:       r2 = 18
      12:       r3 = r0
      13:       call 6
      14:       r0 = 2
      15:       exit

0行目から7行目までに文字列を書きます。 running on CPU%un次に、8 行目でおなじみのものを実行します。 bpf_get_smp_processor_id。 9行目から12行目でヘルパー引数を準備します。 bpf_printk - レジスター r1, r2, r3。 なぜ XNUMX つではなく XNUMX つあるのでしょうか? なぜなら bpf_printk -  これはマクロラッパーです 本当のヘルパーの周り bpf_trace_printk、フォーマット文字列のサイズを渡す必要があります。

ここでいくつかの行を追加しましょう xdp-simple.cプログラムがインターフェースに接続できるようにする lo そして本当に始まりました！

$ cat xdp-simple.c
#include <linux/if_link.h>
#include <err.h>
#include <unistd.h>
#include "xdp-simple.skel.h"

int main(int argc, char **argv)
{
    __u32 flags = XDP_FLAGS_SKB_MODE;
    struct xdp_simple_bpf *obj;

    obj = xdp_simple_bpf__open_and_load();
    if (!obj)
        err(1, "failed to open and/or load BPF objectn");

    bpf_set_link_xdp_fd(1, -1, flags);
    bpf_set_link_xdp_fd(1, bpf_program__fd(obj->progs.simple), flags);

cleanup:
    xdp_simple_bpf__destroy(obj);
}

ここで関数を使用します bpf_set_link_xdp_fd、XDP タイプの BPF プログラムをネットワーク インターフェイスに接続します。 インターフェース番号をハードコーディングしました lo常に 1 です。関数を XNUMX 回実行して、古いプログラムがアタッチされている場合は最初にそれをデタッチします。 今は挑戦する必要がないことに注意してください pause または無限ループ: ローダー プログラムは終了しますが、BPF プログラムはイベント ソースに接続されているため強制終了されません。 ダウンロードと接続が成功すると、ネットワーク パケットが到着するたびにプログラムが起動されます。 lo.

プログラムをダウンロードしてインターフェースを見てみましょう lo:

$ sudo ./xdp-simple
$ sudo bpftool p | grep simple
669: xdp  name simple  tag 4fca62e77ccb43d6  gpl
$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 669

ダウンロードしたプログラムの ID は 669 で、インターフェイス上でも同じ ID が表示されます。 lo。 いくつかの荷物をに送ります 127.0.0.1 (リクエスト + 返信):

$ ping -c1 localhost

次に、デバッグ仮想ファイルの内容を見てみましょう /sys/kernel/debug/tracing/trace_pipe、 その中で bpf_printk 彼のメッセージは次のように書かれています。

# cat /sys/kernel/debug/tracing/trace_pipe
ping-13937 [000] d.s1 442015.377014: bpf_trace_printk: running on CPU0
ping-13937 [000] d.s1 442015.377027: bpf_trace_printk: running on CPU0

XNUMXつのパッケージが見つかりました lo CPU0 で処理されました。初めての本格的な意味のない BPF プログラムが機能しました。

注目に値する bpf_printk デバッグ ファイルに書き込むのは当然のことです。これは運用環境で使用するのに最も成功したヘルパーではありませんが、私たちの目標は単純なものを示すことでした。

BPF プログラムからマップにアクセスする

例: BPF プログラムのマップの使用

前のセクションでは、ユーザー空間からマップを作成して使用する方法を学びました。次に、カーネル部分を見てみましょう。 いつものように、例から始めましょう。 プログラムを書き直してみましょう xdp-simple.bpf.c 次のようにします。

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 8);
    __type(key, u32);
    __type(value, u64);
} woo SEC(".maps");

SEC("xdp/simple")
int simple(void *ctx)
{
    u32 key = bpf_get_smp_processor_id();
    u32 *val;

    val = bpf_map_lookup_elem(&woo, &key);
    if (!val)
        return XDP_ABORTED;

    *val += 1;

    return XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

プログラムの最初にマップ定義を追加しました。 woo: これは、次のような値を格納する 8 要素の配列です。 u64 (C では、このような配列を次のように定義します。 u64 woo[8]）。 番組内で "xdp/simple" 現在のプロセッサ番号を変数に取得します。 key そしてヘルパー関数を使用します bpf_map_lookup_element 配列内の対応するエントリへのポインタを取得し、XNUMX ずつ増やします。 ロシア語に翻訳すると、どの CPU が受信パケットを処理したかに関する統計を計算します。 プログラムを実行してみましょう。

$ clang -O2 -g -c -target bpf -I libbpf/src/root/usr/include xdp-simple.bpf.c -o xdp-simple.bpf.o
$ bpftool gen skeleton xdp-simple.bpf.o > xdp-simple.skel.h
$ clang -O2 -g -I ./libbpf/src/root/usr/include/ -o xdp-simple xdp-simple.c ./libbpf/src/root/usr/lib64/libbpf.a -lelf -lz
$ sudo ./xdp-simple

彼女がつながっていることを確認しましょう lo そしていくつかのパケットを送信します。

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 108

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done

次に、配列の内容を見てみましょう。

$ sudo bpftool map dump name woo
[
    { "key": 0, "value": 0 },
    { "key": 1, "value": 400 },
    { "key": 2, "value": 0 },
    { "key": 3, "value": 0 },
    { "key": 4, "value": 0 },
    { "key": 5, "value": 0 },
    { "key": 6, "value": 0 },
    { "key": 7, "value": 46400 }
]

ほぼすべてのプロセスがCPU7で処理されました。 これは私たちにとって重要ではありません。重要なことは、プログラムが動作し、BPF プログラムからマップにアクセスする方法を理解していることです。 хелперов bpf_mp_*.

神秘のインデックス

したがって、次のような呼び出しを使用して、BPF プログラムからマップにアクセスできます。

val = bpf_map_lookup_elem(&woo, &key);

ヘルパー関数は次のようになります

void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)

しかし、私たちはポインタを渡しています &woo 名前のない構造物に struct { ... }...

プログラムのアセンブラを見ると、値が &woo 実際には定義されていません (行 4):

llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

xdp-simple.bpf.o:       file format elf64-bpf

Disassembly of section xdp/simple:

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
...

これは再配置に含まれています。

$ llvm-readelf -r xdp-simple.bpf.o | head -4

Relocation section '.relxdp/simple' at offset 0xe18 contains 1 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name
0000000000000020  0000002700000001 R_BPF_64_64            0000000000000000 woo

しかし、すでにロードされているプログラムを見ると、正しいマップへのポインタが表示されます (4 行目)。

$ sudo bpftool prog dump x name simple
int simple(void *ctx):
   0: (85) call bpf_get_smp_processor_id#114128
   1: (63) *(u32 *)(r10 -4) = r0
   2: (bf) r2 = r10
   3: (07) r2 += -4
   4: (18) r1 = map[id:64]
...

したがって、ローダー プログラムの起動時に、へのリンクが &woo ライブラリのあるものに置き換えられました libbpf。 まず出力を見てみましょう strace:

$ sudo strace -e bpf ./xdp-simple
...
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, key_size=4, value_size=8, max_entries=8, map_name="woo", ...}, 120) = 4
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, prog_name="simple", ...}, 120) = 5

それがわかります libbpf 地図を作成しました woo そしてプログラムをダウンロードしました simple。 プログラムをロードする方法を詳しく見てみましょう。

• 電話 xdp_simple_bpf__open_and_load ファイルから xdp-simple.skel.h
• その原因 xdp_simple_bpf__load ファイルから xdp-simple.skel.h
• その原因 bpf_object__load_skeleton ファイルから libbpf/src/libbpf.c
• その原因 bpf_object__load_xattr の libbpf/src/libbpf.c

最後の関数は、特に次の関数を呼び出します。 bpf_object__create_maps、既存のマップを作成または開き、マップをファイル記述子に変換します。 (ここで私たちが見るのは BPF_MAP_CREATE 出力内で strace.) 次に関数が呼び出されます。 bpf_object__relocate そして私たちが興味を持っているのは彼女です、なぜなら私たちは見たものを覚えているからです woo 再配置テーブルにあります。 それを探索すると、最終的に関数にたどり着きます。 bpf_program__relocate、どれと マップの再配置を扱う:

case RELO_LD64:
    insn[0].src_reg = BPF_PSEUDO_MAP_FD;
    insn[0].imm = obj->maps[relo->map_idx].fd;
    break;

それで私たちは私たちの指示に従います

18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll

その中のソースレジスタを次のように置き換えます BPF_PSEUDO_MAP_FD、最初の IMM をマップのファイル記述子に追加し、それが次の場合と等しいかどうかを確認します。 0xdeadbeef、その結果、指示を受け取ります

18 11 00 00 ef eb ad de 00 00 00 00 00 00 00 00 r1 = 0 ll

これは、マップ情報がロードされた特定の BPF プログラムに転送される方法です。 この場合、マップは次のように作成できます。 BPF_MAP_CREATEを使用して ID によって開かれます。 BPF_MAP_GET_FD_BY_ID.

合計、使用時 libbpf アルゴリズムは次のとおりです。

• コンパイル中に、マップへのリンクのレコードが再配置テーブルに作成されます。
• libbpf ELF オブジェクト ブックを開き、使用されているすべてのマップを検索し、それらのファイル記述子を作成します。
• ファイル記述子は命令の一部としてカーネルにロードされます。 LD64

ご想像のとおり、今後はさらに多くのことがあり、その核心を調べる必要があります。 幸いなことに、私たちは手がかりを持っています - 私たちは意味を書き留めました BPF_PSEUDO_MAP_FD それをソースレジスターに埋め込むと、すべての聖人の聖地につながるでしょう - kernel/bpf/verifier.c、固有の名前を持つ関数は、ファイル記述子を次のタイプの構造体のアドレスに置き換えます。 struct bpf_map:

static int replace_map_fd_with_map_ptr(struct bpf_verifier_env *env) {
    ...

    f = fdget(insn[0].imm);
    map = __bpf_map_get(f);
    if (insn->src_reg == BPF_PSEUDO_MAP_FD) {
        addr = (unsigned long)map;
    }
    insn[0].imm = (u32)addr;
    insn[1].imm = addr >> 32;

(完全なコードが見つかります リンク）。 したがって、アルゴリズムを拡張できます。

• プログラムのロード中に、検証者はマップの正しい使用法をチェックし、対応する構造体のアドレスを書き込みます。 struct bpf_map

を使用して ELF バイナリをダウンロードする場合 libbpf 他にもたくさんのことが起こっていますが、それについては別の記事で説明します。

libbpf を使用しないプログラムとマップのロード

約束どおり、マップを使用するプログラムを助けなしで作成してロードする方法を知りたい読者のための例をここに示します。 libbpf。 これは、依存関係を構築できない環境で作業している場合、すべてのビットを保存する場合、または次のようなプログラムを作成する場合に便利です。 ply、BPF バイナリ コードをオンザフライで生成します。

ロジックを理解しやすくするために、次の目的のために例を書き直します。 xdp-simple。 この例で説明したプログラムの完全な、わずかに拡張されたコードは、次の場所にあります。 要旨.

アプリケーションのロジックは次のとおりです。

• タイプマップを作成する BPF_MAP_TYPE_ARRAY コマンドを使用して BPF_MAP_CREATE,
• このマップを使用するプログラムを作成し、
• プログラムをインターフェースに接続する lo,

これを人間に訳すと、

int main(void)
{
    int map_fd, prog_fd;

    map_fd = map_create();
    if (map_fd < 0)
        err(1, "bpf: BPF_MAP_CREATE");

    prog_fd = prog_load(map_fd);
    if (prog_fd < 0)
        err(1, "bpf: BPF_PROG_LOAD");

    xdp_attach(1, prog_fd);
}

それは map_create システムコールに関する最初の例で行ったのと同じ方法でマップを作成します。 bpf - 「カーネル、次のような 8 要素の配列の形式で新しいマップを作成してください」 __u64 ファイル記述子を返してください":

static int map_create()
{
    union bpf_attr attr;

    memset(&attr, 0, sizeof(attr));
    attr.map_type = BPF_MAP_TYPE_ARRAY,
    attr.key_size = sizeof(__u32),
    attr.value_size = sizeof(__u64),
    attr.max_entries = 8,
    strncpy(attr.map_name, "woo", sizeof(attr.map_name));
    return syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr));
}

プログラムのロードも簡単です。

static int prog_load(int map_fd)
{
    union bpf_attr attr;
    struct bpf_insn insns[] = {
        ...
    };

    memset(&attr, 0, sizeof(attr));
    attr.prog_type = BPF_PROG_TYPE_XDP;
    attr.insns     = ptr_to_u64(insns);
    attr.insn_cnt  = sizeof(insns)/sizeof(insns[0]);
    attr.license   = ptr_to_u64("GPL");
    strncpy(attr.prog_name, "woo", sizeof(attr.prog_name));
    return syscall(__NR_bpf, BPF_PROG_LOAD, &attr, sizeof(attr));
}

難しい部分 prog_load 構造体の配列としての BPF プログラムの定義です。 struct bpf_insn insns[]。 ただし、C で作成したプログラムを使用しているため、少しチートすることができます。

$ llvm-objdump -D --section xdp/simple xdp-simple.bpf.o

0000000000000000 <simple>:
       0:       85 00 00 00 08 00 00 00 call 8
       1:       63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0
       2:       bf a2 00 00 00 00 00 00 r2 = r10
       3:       07 02 00 00 fc ff ff ff r2 += -4
       4:       18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll
       6:       85 00 00 00 01 00 00 00 call 1
       7:       b7 01 00 00 00 00 00 00 r1 = 0
       8:       15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2>
       9:       61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0)
      10:       07 01 00 00 01 00 00 00 r1 += 1
      11:       63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1
      12:       b7 01 00 00 02 00 00 00 r1 = 2

0000000000000068 <LBB0_2>:
      13:       bf 10 00 00 00 00 00 00 r0 = r1
      14:       95 00 00 00 00 00 00 00 exit

合計 14 個の命令を次のような構造の形式で記述する必要があります。 struct bpf_insn (アドバイス： 上記のダンプを取得し、手順セクションをもう一度読み、開きます linux/bpf.h и linux/bpf_common.h そして判断しようとする struct bpf_insn insns[] 自分で):

struct bpf_insn insns[] = {
    /* 85 00 00 00 08 00 00 00 call 8 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 8,
    },

    /* 63 0a fc ff 00 00 00 00 *(u32 *)(r10 - 4) = r0 */
    {
        .code = BPF_MEM | BPF_STX,
        .off = -4,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_10,
    },

    /* bf a2 00 00 00 00 00 00 r2 = r10 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_10,
        .dst_reg = BPF_REG_2,
    },

    /* 07 02 00 00 fc ff ff ff r2 += -4 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_2,
        .imm = -4,
    },

    /* 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll */
    {
        .code = BPF_LD | BPF_DW | BPF_IMM,
        .src_reg = BPF_PSEUDO_MAP_FD,
        .dst_reg = BPF_REG_1,
        .imm = map_fd,
    },
    { }, /* placeholder */

    /* 85 00 00 00 01 00 00 00 call 1 */
    {
        .code = BPF_JMP | BPF_CALL,
        .imm = 1,
    },

    /* b7 01 00 00 00 00 00 00 r1 = 0 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 0,
    },

    /* 15 00 04 00 00 00 00 00 if r0 == 0 goto +4 <LBB0_2> */
    {
        .code = BPF_JMP | BPF_JEQ | BPF_K,
        .off = 4,
        .src_reg = BPF_REG_0,
        .imm = 0,
    },

    /* 61 01 00 00 00 00 00 00 r1 = *(u32 *)(r0 + 0) */
    {
        .code = BPF_MEM | BPF_LDX,
        .off = 0,
        .src_reg = BPF_REG_0,
        .dst_reg = BPF_REG_1,
    },

    /* 07 01 00 00 01 00 00 00 r1 += 1 */
    {
        .code = BPF_ALU64 | BPF_ADD | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 1,
    },

    /* 63 10 00 00 00 00 00 00 *(u32 *)(r0 + 0) = r1 */
    {
        .code = BPF_MEM | BPF_STX,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* b7 01 00 00 02 00 00 00 r1 = 2 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_K,
        .dst_reg = BPF_REG_1,
        .imm = 2,
    },

    /* <LBB0_2>: bf 10 00 00 00 00 00 00 r0 = r1 */
    {
        .code = BPF_ALU64 | BPF_MOV | BPF_X,
        .src_reg = BPF_REG_1,
        .dst_reg = BPF_REG_0,
    },

    /* 95 00 00 00 00 00 00 00 exit */
    {
        .code = BPF_JMP | BPF_EXIT
    },
};

これを自分で作成したわけではない人のための演習 - 検索 map_fd.

私たちのプログラムにはもう XNUMX つ未公開の部分が残っています - xdp_attach。 残念ながら、XDP のようなプログラムはシステム コールを使用して接続することはできません。 bpf。 BPF と XDP を作成した人々はオンライン Linux コミュニティの出身者でした。つまり、彼らは最もよく知っているものを使用していました (ただし、そうではありません)。 普通の people) カーネルと対話するためのインターフェイス: ネットリンクソケット、こちらも参照 RFC3549。 最も簡単な実装方法 xdp_attach からコードをコピーしています libbpf、つまりファイルから netlink.cこれを少し短くして、次のようにしました。

ネットリンクソケットの世界へようこそ

ネットリンクソケットタイプを開きます NETLINK_ROUTE:

int netlink_open(__u32 *nl_pid)
{
    struct sockaddr_nl sa;
    socklen_t addrlen;
    int one = 1, ret;
    int sock;

    memset(&sa, 0, sizeof(sa));
    sa.nl_family = AF_NETLINK;

    sock = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
    if (sock < 0)
        err(1, "socket");

    if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK, &one, sizeof(one)) < 0)
        warnx("netlink error reporting not supported");

    if (bind(sock, (struct sockaddr *)&sa, sizeof(sa)) < 0)
        err(1, "bind");

    addrlen = sizeof(sa);
    if (getsockname(sock, (struct sockaddr *)&sa, &addrlen) < 0)
        err(1, "getsockname");

    *nl_pid = sa.nl_pid;
    return sock;
}

このソケットから次の情報を読み取ります。

static int bpf_netlink_recv(int sock, __u32 nl_pid, int seq)
{
    bool multipart = true;
    struct nlmsgerr *errm;
    struct nlmsghdr *nh;
    char buf[4096];
    int len, ret;

    while (multipart) {
        multipart = false;
        len = recv(sock, buf, sizeof(buf), 0);
        if (len < 0)
            err(1, "recv");

        if (len == 0)
            break;

        for (nh = (struct nlmsghdr *)buf; NLMSG_OK(nh, len);
                nh = NLMSG_NEXT(nh, len)) {
            if (nh->nlmsg_pid != nl_pid)
                errx(1, "wrong pid");
            if (nh->nlmsg_seq != seq)
                errx(1, "INVSEQ");
            if (nh->nlmsg_flags & NLM_F_MULTI)
                multipart = true;
            switch (nh->nlmsg_type) {
                case NLMSG_ERROR:
                    errm = (struct nlmsgerr *)NLMSG_DATA(nh);
                    if (!errm->error)
                        continue;
                    ret = errm->error;
                    // libbpf_nla_dump_errormsg(nh); too many code to copy...
                    goto done;
                case NLMSG_DONE:
                    return 0;
                default:
                    break;
            }
        }
    }
    ret = 0;
done:
    return ret;
}

最後に、ソケットを開いて、ファイル記述子を含む特別なメッセージをソケットに送信する関数を次に示します。

static int xdp_attach(int ifindex, int prog_fd)
{
    int sock, seq = 0, ret;
    struct nlattr *nla, *nla_xdp;
    struct {
        struct nlmsghdr  nh;
        struct ifinfomsg ifinfo;
        char             attrbuf[64];
    } req;
    __u32 nl_pid = 0;

    sock = netlink_open(&nl_pid);
    if (sock < 0)
        return sock;

    memset(&req, 0, sizeof(req));
    req.nh.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
    req.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
    req.nh.nlmsg_type = RTM_SETLINK;
    req.nh.nlmsg_pid = 0;
    req.nh.nlmsg_seq = ++seq;
    req.ifinfo.ifi_family = AF_UNSPEC;
    req.ifinfo.ifi_index = ifindex;

    /* started nested attribute for XDP */
    nla = (struct nlattr *)(((char *)&req)
            + NLMSG_ALIGN(req.nh.nlmsg_len));
    nla->nla_type = NLA_F_NESTED | IFLA_XDP;
    nla->nla_len = NLA_HDRLEN;

    /* add XDP fd */
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FD;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(int);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &prog_fd, sizeof(prog_fd));
    nla->nla_len += nla_xdp->nla_len;

    /* if user passed in any flags, add those too */
    __u32 flags = XDP_FLAGS_SKB_MODE;
    nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
    nla_xdp->nla_type = IFLA_XDP_FLAGS;
    nla_xdp->nla_len = NLA_HDRLEN + sizeof(flags);
    memcpy((char *)nla_xdp + NLA_HDRLEN, &flags, sizeof(flags));
    nla->nla_len += nla_xdp->nla_len;

    req.nh.nlmsg_len += NLA_ALIGN(nla->nla_len);

    if (send(sock, &req, req.nh.nlmsg_len, 0) < 0)
        err(1, "send");
    ret = bpf_netlink_recv(sock, nl_pid, seq);

cleanup:
    close(sock);
    return ret;
}

これで、すべてをテストする準備が整いました。

$ cc nolibbpf.c -o nolibbpf
$ sudo strace -e bpf ./nolibbpf
bpf(BPF_MAP_CREATE, {map_type=BPF_MAP_TYPE_ARRAY, map_name="woo", ...}, 72) = 3
bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_XDP, insn_cnt=15, prog_name="woo", ...}, 72) = 4
+++ exited with 0 +++

私たちのプログラムが接続したかどうかを見てみましょう lo:

$ ip l show dev lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    prog/xdp id 160

ping を送信して地図を見てみましょう。

$ for s in `seq 234`; do sudo ping -f -c 100 127.0.0.1 >/dev/null 2>&1; done
$ sudo bpftool m dump name woo
key: 00 00 00 00  value: 90 01 00 00 00 00 00 00
key: 01 00 00 00  value: 00 00 00 00 00 00 00 00
key: 02 00 00 00  value: 00 00 00 00 00 00 00 00
key: 03 00 00 00  value: 00 00 00 00 00 00 00 00
key: 04 00 00 00  value: 00 00 00 00 00 00 00 00
key: 05 00 00 00  value: 00 00 00 00 00 00 00 00
key: 06 00 00 00  value: 40 b5 00 00 00 00 00 00
key: 07 00 00 00  value: 00 00 00 00 00 00 00 00
Found 8 elements

万歳、すべてうまくいきます。 ちなみに、マップは再びバイト形式で表示されることに注意してください。 これは、とは異なり、 libbpf 型情報 (BTF) をロードしませんでした。 しかし、これについては次回に詳しく説明します。

開発ツール

このセクションでは、最小限の BPF 開発者ツールキットについて説明します。

一般的に言えば、BPF プログラムを開発するために特別なものは何も必要ありません。BPF は適切なディストリビューション カーネル上で実行され、プログラムは以下を使用して構築されます。 clang、パッケージから供給できます。 ただし、BPF は開発中であるため、カーネルとツールは常に変更されており、2019 年以降の昔ながらの方法を使用して BPF プログラムを作成したくない場合は、コンパイルする必要があります。

• llvm/clang
• pahole
• その核心
• bpftool

(参考までに、このセクションと記事内のすべての例は Debian 10 で実行されました。)

llvm/クラング

BPF は LLVM と親和性があり、最近では BPF 用のプログラムは gcc を使用してコンパイルできるようになりましたが、現在の開発はすべて LLVM に対して行われています。 したがって、まず第一に、現在のバージョンをビルドします clang git から:

$ sudo apt install ninja-build
$ git clone --depth 1 https://github.com/llvm/llvm-project.git
$ mkdir -p llvm-project/llvm/build/install
$ cd llvm-project/llvm/build
$ cmake .. -G "Ninja" -DLLVM_TARGETS_TO_BUILD="BPF;X86" 
                      -DLLVM_ENABLE_PROJECTS="clang" 
                      -DBUILD_SHARED_LIBS=OFF 
                      -DCMAKE_BUILD_TYPE=Release 
                      -DLLVM_BUILD_RUNTIME=OFF
$ time ninja
... много времени спустя
$

これで、すべてが正しく結合されているかどうかを確認できます。

$ ./bin/llc --version
LLVM (http://llvm.org/):
  LLVM version 11.0.0git
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver1

  Registered Targets:
    bpf    - BPF (host endian)
    bpfeb  - BPF (big endian)
    bpfel  - BPF (little endian)
    x86    - 32-bit X86: Pentium-Pro and above
    x86-64 - 64-bit X86: EM64T and AMD64

（組立説明 clang 私がから取った bpf_devel_QA.)

構築したばかりのプログラムをインストールするのではなく、単に追加するだけです。 PATHたとえば、次のようになります。

export PATH="`pwd`/bin:$PATH"

(これは追加できます .bashrc または別のファイルに保存します。 個人的にはこんなものを追加しています ~/bin/activate-llvm.sh そして必要なときはそうします . activate-llvm.sh.)

パホールとBTF

ユーティリティ pahole カーネルを構築するときに使用され、BTF 形式でデバッグ情報を作成します。 BTF テクノロジーの詳細については、便利なので使いたいという事実以外、この記事では詳しく説明しません。 したがって、カーネルをビルドする場合は、最初にビルドしてください pahole （なし pahole オプションを使用してカーネルをビルドすることはできません CONFIG_DEBUG_INFO_BTF:

$ git clone https://git.kernel.org/pub/scm/devel/pahole/pahole.git
$ cd pahole/
$ sudo apt install cmake
$ mkdir build
$ cd build/
$ cmake -D__LIB=lib ..
$ make
$ sudo make install
$ which pahole
/usr/local/bin/pahole

BPF を実験するためのカーネル

BPFの可能性を探る上で、自分なりのコアを組み立てていきたいと思っています。 ディストリビューション カーネル上で BPF プログラムをコンパイルしてロードできるため、これは一般的には必要ありませんが、独自のカーネルを使用すると、最新の BPF 機能を使用できるようになり、ディストリビューションに反映されるまでに最長で数か月かかります。または、一部のデバッグ ツールの場合と同様に、予見可能な将来にはまったくパッケージ化されなくなります。 また、独自のコアにより、コードを試してみることが重要であると感じられます。

カーネルを構築するには、まずカーネル自体が必要で、次にカーネル構成ファイルが必要です。 BPF を実験するには、通常のメソッドを使用できます。 バニラ カーネルまたは開発カーネルの XNUMX つ。 歴史的に、BPF の開発は Linux ネットワーキング コミュニティ内で行われているため、すべての変更は遅かれ早かれ、Linux ネットワーキング メンテナである David Miller を介して行われます。 編集または新機能の性質に応じて、ネットワークの変更は XNUMX つのコアのいずれかに分類されます。 net または net-next。 BPF の変更は、以下の間で同じ方法で配布されます。 bpf и bpf-next、その後、それぞれ net と net-next にプールされます。 詳細については、を参照してください。 bpf_devel_QA и netdev-FAQ。 したがって、好みとテスト対象のシステムの安定性のニーズに基づいてカーネルを選択してください (*-next カーネルはリストされているものの中で最も不安定です)。

カーネル構成ファイルの管理方法について説明することは、この記事の範囲を超えています。読者はその方法をすでに知っているか、またはそのいずれかを前提としています。 学ぶ準備ができている 自分自身で。 ただし、次の手順は、BPF 対応システムを動作させるのに多かれ少なかれ十分です。

上記のカーネルのいずれかをダウンロードします。

$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
$ cd bpf-next

最小限の動作カーネル構成を構築します。

$ cp /boot/config-`uname -r` .config
$ make localmodconfig

ファイル内の BPF オプションを有効にする .config あなた自身の選択（おそらく CONFIG_BPF systemd が使用するため、すでに有効になっています)。 この記事で使用したカーネルのオプションのリストは次のとおりです。

CONFIG_CGROUP_BPF=y
CONFIG_BPF=y
CONFIG_BPF_LSM=y
CONFIG_BPF_SYSCALL=y
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
CONFIG_BPF_JIT_ALWAYS_ON=y
CONFIG_BPF_JIT_DEFAULT_ON=y
CONFIG_IPV6_SEG6_BPF=y
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
CONFIG_NET_CLS_BPF=y
CONFIG_NET_ACT_BPF=y
CONFIG_BPF_JIT=y
CONFIG_BPF_STREAM_PARSER=y
CONFIG_LWTUNNEL_BPF=y
CONFIG_HAVE_EBPF_JIT=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_KPROBE_OVERRIDE=y
CONFIG_DEBUG_INFO_BTF=y

その後、モジュールとカーネルを簡単に組み立ててインストールできます (ちなみに、新しく組み立てられたものを使用してカーネルを組み立てることもできます) clang追加することで CC=clang):

$ make -s -j $(getconf _NPROCESSORS_ONLN)
$ sudo make modules_install
$ sudo make install

そして新しいカーネルで再起動します（私はこれに使用します） kexec パッケージから kexec-tools):

v=5.8.0-rc6+ # если вы пересобираете текущее ядро, то можно делать v=`uname -r`
sudo kexec -l -t bzImage /boot/vmlinuz-$v --initrd=/boot/initrd.img-$v --reuse-cmdline &&
sudo kexec -e

bpftool

この記事で最もよく使用されるユーティリティは次のとおりです。 bpftool、Linux カーネルの一部として提供されます。 これは、BPF 開発者によって BPF 開発者のために作成および保守されており、プログラムのロード、マップの作成と編集、BPF エコシステムの探索など、あらゆるタイプの BPF オブジェクトの管理に使用できます。 マニュアルページのソースコード形式のドキュメントが見つかります。 中心部にある または、すでにコンパイルされている、 ネットワーク.

この記事の執筆時点 bpftool RHEL、Fedora、および Ubuntu 用にのみ既製で提供されています (たとえば、を参照) このスレッドパッケージングの未完の物語を語る bpftool Debian では)。 ただし、すでにカーネルを構築している場合は、次のように構築します。 bpftool パイのように簡単:

$ cd ${linux}/tools/bpf/bpftool
# ... пропишите пути к последнему clang, как рассказано выше
$ make -s

Auto-detecting system features:
...                        libbfd: [ on  ]
...        disassembler-four-args: [ on  ]
...                          zlib: [ on  ]
...                        libcap: [ on  ]
...               clang-bpf-co-re: [ on  ]

Auto-detecting system features:
...                        libelf: [ on  ]
...                          zlib: [ on  ]
...                           bpf: [ on  ]

$

（ここ ${linux} - これはカーネル ディレクトリです。) これらのコマンドを実行した後 bpftool ディレクトリに収集されます ${linux}/tools/bpf/bpftool そしてそれをパスに追加できます（まずユーザーに追加します） root) または単にコピーする /usr/local/sbin.

収集します bpftool 後者を使用するのが最善です clang、上記のように組み立てられ、正しく組み立てられているかどうかを確認します。たとえば、次のコマンドを使用します。

$ sudo bpftool feature probe kernel
Scanning system configuration...
bpf() syscall for unprivileged users is enabled
JIT compiler is enabled
JIT compiler hardening is disabled
JIT compiler kallsyms exports are enabled for root
...

これにより、カーネルでどの BPF 機能が有効になっているかが表示されます。

ちなみに、先ほどのコマンドは次のように実行できます。

# bpftool f p k

これは、パッケージのユーティリティと同様に行われます。 iproute2、ここで、たとえば次のように言えます。 ip a s eth0 代わりに ip addr show dev eth0.

まとめ

BPF を使用すると、ノミに靴を履かせて、コアの機能を効果的に測定し、その場で変更することができます。 このシステムは、UNIX の最良の伝統に従って、非常に成功したことが判明しました。カーネルを (再) プログラムできるシンプルなメカニズムにより、膨大な数の人々や組織が実験することができました。 また、実験や BPF インフラストラクチャ自体の開発はまだ完成には程遠いものの、システムにはすでに安定した ABI が備わっており、信頼性が高く、最も重要なことに効果的なビジネス ロジックを構築できます。

私の意見では、このテクノロジーがこれほど普及したのは、一方では次のようなことができるためです。 遊ぶ （マシンのアーキテクチャは一晩で多かれ少なかれ理解できます）、一方で、その出現前に（美しく）解決できなかった問題を解決することもできます。 これら XNUMX つのコンポーネントを組み合わせることで、人々は実験と夢を見ることを強いられ、それがますます革新的なソリューションの出現につながります。

この記事は特に短いものではありませんが、BPF の世界を紹介するだけであり、「高度な」機能やアーキテクチャの重要な部分については説明しません。 今後の計画は次のようなものです。次の記事では BPF プログラム タイプの概要を説明し (5.8 カーネルでは 30 のプログラム タイプがサポートされています)、最後にカーネル トレース プログラムを使用して実際の BPF アプリケーションを作成する方法を見ていきます。例として、BPF アーキテクチャに関するより詳細なコースを受講し、その後に BPF ネットワーキングとセキュリティ アプリケーションの例を説明します。

このシリーズの以前の記事

1. 小さな子供のための BPF、パート XNUMX: 古典的な BPF

リンク

1. BPF および XDP リファレンス ガイド — 繊毛、より正確には、BPF の作成者および保守者の XNUMX 人である Daniel Borkman からの BPF に関する文書。 これは最初の本格的な記述の XNUMX つであり、ダニエルは自分が何について書いているのかを正確に理解しており、そこに間違いがないという点で他の記述とは異なります。 特に、このドキュメントでは、よく知られたユーティリティを使用して XDP および TC タイプの BPF プログラムを操作する方法について説明します。 ip パッケージから iproute2.

2. ドキュメント/ネットワーク/filter.txt — クラシックおよび拡張 BPF のドキュメントを含むオリジナル ファイル。 アセンブリ言語と技術的なアーキテクチャの詳細を詳しく知りたい場合は、ぜひ読んでください。

3. Facebook からの BPF に関するブログ。 Alexei Starovoitov (eBPF の作者) と Andrii Nakryiko - (メンテナ) がそこに書いているように、めったに更新されませんが、適切に更新されます。 libbpf).

4. bpftool の秘密。 Quentin Monnet による楽しい Twitter スレッド。bpftool の使用例と秘密が記載されています。

5. BPF の詳細: 読み物リスト。 Quentin Monnet による BPF ドキュメントへのリンクの巨大な (そして現在も維持されている) リスト。

出所： habr.com