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

Berkeley Packet Filters (BPF) は、数年前から英語の技術出版物の表紙を飾っている Linux カーネル テクノロジです。 カンファレンスでは、BPF の使用と開発に関する報告が数多く行われます。 Linux ネットワーク サブシステム メンテナの David Miller 氏が Linux Plumbers 2018 で講演 「この話は XDP に関するものではありません」 (XDP は BPF の使用例の XNUMX つです)。 ブレンダン・グレッグが次のタイトルで講演 Linux BPF のスーパーパワー。 トーケ・ホイランド＝ヨルゲンセン 笑うカーネルがマイクロカーネルになっているということです。 トーマス・グラフは次のような考えを推進しています。 BPFはカーネル用のJavaScriptです.

Habré に関する BPF の体系的な説明はまだありません。そのため、一連の記事で、このテクノロジーの歴史について説明し、アーキテクチャと開発ツールについて説明し、BPF の使用の応用分野と実践の概要を説明しようと思います。 シリーズのこの記事ゼロでは、古典的な BPF の歴史とアーキテクチャを説明し、その動作原理の秘密も明らかにします。 tcpdump, seccomp, strace、имногоедругое。

BPF の開発は Linux ネットワーク コミュニティによって管理されており、BPF の既存の主なアプリケーションはネットワークに関連しているため、許可を得ています。 @ユーカリオット、素晴らしいシリーズに敬意を表して、私はこのシリーズを「小さなもののためのBPF」と名付けました。 「小さな子どもたちのネットワーク」.

BPF の歴史の短いコース(c)

最新の BPF テクノロジは、同じ名前の古いテクノロジを改良および拡張したバージョンであり、現在は混乱を避けるためにクラシック BPF と呼ばれています。 有名なユーティリティは古典的な BPF に基づいて作成されました tcpdump、メカニズム seccomp、あまり知られていないモジュールも xt_bpf のために iptables と分類子 cls_bpf。 最新の Linux では、クラシック BPF プログラムは自動的に新しい形式に変換されますが、ユーザーの観点から見ると、API はそのまま残されており、この記事で説明するように、クラシック BPF の新しい用途がまだ見つかっています。 この理由から、また、Linux での古典的な BPF の開発の歴史をたどると、それがどのように、そしてなぜ現代の形に進化したのかがより明確になるため、私は古典的な BPF に関する記事から始めることにしました。

前世紀の XNUMX 年代の終わりに、有名なローレンス バークレー研究所のエンジニアは、前世紀の XNUMX 年代後半には最新だったハードウェア上でネットワーク パケットを適切にフィルタリングする方法の問題に興味を持ちました。 もともと CSPF (CMU/Stanford Packet Filter) テクノロジーで実装されたフィルタリングの基本的な考え方は、不要なパケットをできるだけ早くフィルタリングすることでした。 これにより、不要なデータがユーザー空間にコピーされることが回避されるためです。 カーネル空間でユーザー コードを実行するためのランタイム セキュリティを提供するために、サンドボックス仮想マシンが使用されました。

ただし、既存のフィルターの仮想マシンはスタックベースのマシンで実行されるように設計されており、新しい RISC マシンではそれほど効率的に実行されませんでした。 その結果、バークレー研究所のエンジニアの努力により、新しい BPF (バークレー パケット フィルター) テクノロジーが開発されました。その仮想マシン アーキテクチャは、以下のようなよく知られた製品の主力である Motorola 6502 プロセッサに基づいて設計されました。 アップルII または NES。 新しい仮想マシンは、既存のソリューションと比較してフィルターのパフォーマンスを数十倍向上させました。

BPF マシンのアーキテクチャ

事例を分析しながら、実践的な方法で建築について学びます。 ただし、まず、マシンにユーザーがアクセスできる 32 つの XNUMX ビット レジスタ、つまりアキュムレータがあったとします。 A とインデックスレジスタ X、書き込みとその後の読み取りに使用できる 64 バイトのメモリ (16 ワード)、およびこれらのオブジェクトを操作するための小規模なコマンド システム。 条件式を実装するためのジャンプ命令もプログラム内で使用できましたが、プログラムのタイムリーな完了を保証するために、ジャンプは前方にのみ行うことができ、特にループを作成することは禁止されていました。

マシンを起動するための一般的なスキームは次のとおりです。 ユーザーは、BPF アーキテクチャ用のプログラムを作成し、 いくつか カーネルメカニズム (システムコールなど)、プログラムをロードして接続します。 一部の人に カーネル内のイベント ジェネレーターに送信されます (たとえば、イベントはネットワーク カード上の次のパケットの到着です)。 イベントが発生すると、カーネルはプログラムを実行し（たとえばインタープリタ内で）、マシンのメモリは 一部の人に カーネル メモリ領域 (受信パケットのデータなど)。

例を見て始めるには上記で十分です。必要に応じてシステムとコマンドの形式について理解していきます。 仮想マシンのコマンド システムをすぐに調べて、そのすべての機能について知りたい場合は、元の記事を読むことができます。 BSDパケットフィルター および/またはファイルの前半 ドキュメント/ネットワーク/filter.txt カーネルのドキュメントから。 また、プレゼンテーションの勉強もできます libpcap: パケット キャプチャのアーキテクチャと最適化手法、BPF の著者の XNUMX 人であるマッキャンが創造の歴史について語ります。 libpcap.

次に、Linux でのクラシック BPF の使用に関する重要な例をすべて検討していきます。 tcpdump (libpcap)、セコンプ、 xt_bpf, cls_bpf.

tcpdump

BPF の開発は、よく知られたユーティリティであるパケット フィルタリングのフロントエンドの開発と並行して行われました。 tcpdump。 これは、多くのオペレーティング システムで利用できるクラシック BPF を使用する最も古く、最も有名な例であるため、これを使用してテクノロジの研究を開始します。

(この記事のすべての例は Linux 上で実行しました 5.6.0-rc6。 一部のコマンドの出力は、読みやすくするために編集されています。)

例: IPv6 パケットの観察

インターフェイス上のすべての IPv6 パケットを調べたいと想像してみましょう。 eth0。 これを行うには、プログラムを実行します tcpdump 簡単なフィルターを使って ip6:

$ sudo tcpdump -i eth0 ip6

この場合、 tcpdump フィルターをコンパイルします ip6 BPF アーキテクチャのバイトコードに変換してカーネルに送信します (セクションの詳細を参照) Tcpdump:読み込み中）。 ロードされたフィルタは、インターフェイスを通過するすべてのパケットに対して実行されます。 eth0。 フィルターがゼロ以外の値を返した場合 n、その後、まで n パケットのバイトがユーザー空間にコピーされ、出力に表示されます。 tcpdump.

どのバイトコードがカーネルに送信されたかを簡単に知ることができることがわかりました。 tcpdump の助けを借りて tcpdump、オプションを付けて実行すると -d:

$ sudo tcpdump -i eth0 -d ip6
(000) ldh      [12]
(001) jeq      #0x86dd          jt 2    jf 3
(002) ret      #262144
(003) ret      #0

XNUMX行目でコマンドを実行します ldh [12]、これは「レジスタへのロード」を表します。 A アドレス 16 にある半ワード (12 ビット) ですが、唯一の問題は、どのような種類のメモリをアドレス指定しているのかということです。 答えは、 x 始まる (x+1)分析されたネットワークパケットの第 XNUMX バイト。 イーサネットインターフェイスからパケットを読み取ります eth0そしてこれ 手段パケットは次のようになります (簡単にするために、パケット内に VLAN タグがないと仮定します)。

       6              6          2
|Destination MAC|Source MAC|Ether Type|...|

したがって、コマンドを実行した後、 ldh [12] レジスターにある A フィールドがあるでしょう Ether Type — このイーサネット フレームで送信されるパケットのタイプ。 1 行目でレジスタの内容を比較します。 A (パッケージタイプ) c 0x86ddそしてこれ そしてあります 私たちが関心のあるタイプは IPv6 です。 1 行目には、比較コマンドに加えて、さらに XNUMX つの列があります。 jt 2 и jf 3 — 比較が成功した場合に進む必要があるマーク (A == 0x86dd）そして失敗しました。 したがって、成功した場合 (IPv6) は 2 行目に進み、失敗した場合は 3 行目に進みます。 3 行目ではプログラムはコード 0 (パケットをコピーしない) で終了し、2 行目ではプログラムはコードで終了します。 262144 (最大 256 キロバイトのパッケージをコピーしてください)。

より複雑な例: 宛先ポートごとに TCP パケットを調べます

宛先ポート 666 を持つすべての TCP パケットをコピーするフィルターがどのようなものかを見てみましょう。IPv4 の場合はより単純であるため、IPv6 の場合を検討します。 この例を学習した後、演習として IPv6 フィルターを自分で調べることができます (ip6 and tcp dst port 666) と一般的な場合のフィルター (tcp dst port 666）。 したがって、関心のあるフィルターは次のようになります。

$ sudo tcpdump -i eth0 -d ip and tcp dst port 666
(000) ldh      [12]
(001) jeq      #0x800           jt 2    jf 10
(002) ldb      [23]
(003) jeq      #0x6             jt 4    jf 10
(004) ldh      [20]
(005) jset     #0x1fff          jt 10   jf 6
(006) ldxb     4*([14]&0xf)
(007) ldh      [x + 16]
(008) jeq      #0x29a           jt 9    jf 10
(009) ret      #262144
(010) ret      #0

行 0 と行 1 が何をするかはすでにわかっています。 2 行目で、これが IPv4 パケット (Ether Type = 0x800) そしてそれをレジスタにロードします A パケットの 24 バイト目。 私たちのパッケージは次のようになります

       14            8      1     1
|ethernet header|ip fields|ttl|protocol|...|

これはレジスタにロードすることを意味します A IP ヘッダーの Protocol フィールド。TCP パケットのみをコピーするため、これは論理的です。 プロトコルを比較します 0x6 (IPPROTO_TCP) 3 行目。

4 行目と 5 行目で、アドレス 20 にあるハーフワードをロードし、次のコマンドを使用します。 jset XNUMX つのうちの XNUMX つが設定されているかどうかを確認します フラグ - 発行されたマスクの着用 jset 最上位 XNUMX ビットはクリアされます。 XNUMX ビットのうち XNUMX ビットは、パケットがフラグメント化された IP パケットの一部であるかどうか、また、フラグメント化されている場合は最後のフラグメントであるかどうかを示します。 XNUMX 番目のビットは予約されており、ゼロにする必要があります。 整数パケットも壊れたパケットもチェックしたくないので、XNUMX ビットすべてをチェックします。

このリストの中で最も興味深いのは行 6 です。 表現 ldxb 4*([14]&0xf) レジスタにロードすることを意味します X パケットの 4 番目のバイトの下位 XNUMX ビットを XNUMX で乗算したもの。XNUMX 番目のバイトの下位 XNUMX ビットはフィールドです。 インターネットヘッダーの長さ IPv4 ヘッダー。ヘッダーの長さをワードで保存するため、4 を掛ける必要があります。興味深いことに、式は 4*([14]&0xf) は、この形式でのみ、またレジスタに対してのみ使用できる特別なアドレス指定スキームの指定です。 X、つまり私たちにも言えません ldb 4*([14]&0xf) また ldxb 5*([14]&0xf) (指定できるのは別のオフセットのみです。たとえば、 ldxb 4*([16]&0xf)）。 このアドレス指定スキームが正確に受信するために BPF に追加されたことは明らかです。 X (インデックス レジスタ) IPv4 ヘッダーの長さ。

したがって、7行目で半分の単語をロードしようとします (X+16)。 14 バイトがイーサネット ヘッダーによって占められていることを思い出してください。 X IPv4 ヘッダーの長さが含まれているため、 A TCP 宛先ポートがロードされています:

       14           X           2             2
|ethernet header|ip header|source port|destination port|

最後に、8 行目で宛先ポートを目的の値と比較し、9 行目または 10 行目でパケットをコピーするかどうかの結果を返します。

Tcpdump:読み込み中

前の例では、パケット フィルタリングのために BPF バイトコードをカーネルに正確にロードする方法については特に詳しく説明しませんでした。 一般的に言えば、 tcpdump 多くのシステムに移植され、フィルターを操作するために使用されます。 tcpdump 図書館を利用する libpcap。 簡単に言うと、次を使用してインターフェースにフィルターを配置します。 libpcap、次のことを行う必要があります。

• 型記述子を作成する pcap_t インターフェース名から: pcap_create,
• インターフェースをアクティブ化します: pcap_activate,
• コンパイルフィルター: pcap_compile,
• フィルターを接続します: pcap_setfilter.

機能がどのように機能するかを確認するには pcap_setfilter Linux で実装されているものを使用します。 strace (一部の行は削除されています):

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

出力の最初の XNUMX 行で作成します。 生のソケット すべてのイーサネット フレームを読み取り、インターフェイスにバインドします。 eth0。 から 私たちの最初の例 私たちはフィルターがあることを知っています ip は XNUMX つの BPF 命令で構成され、XNUMX 行目ではオプションの使用方法が示されています。 SO_ATTACH_FILTER システムコール setsockopt 長さ 4 のフィルターをロードして接続します。これがフィルターです。

従来の BPF では、フィルターのロードと接続は常にアトミック操作として発生しますが、新しいバージョンの BPF では、プログラムのロードとイベント ジェネレーターへのバインドが時間的に分離されることに注意してください。

隠された真実

出力のもう少し完全なバージョンは次のようになります。

$ sudo strace -f -e trace=%network tcpdump -p -i eth0 ip
socket(AF_PACKET, SOCK_RAW, 768)        = 3
bind(3, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("eth0"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0xbeefbeefbeef}, 16) = 0
recvfrom(3, 0x7ffcad394257, 1, MSG_TRUNC, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=4, filter=0xb00bb00bb00b}, 16) = 0
...

上で述べたように、フィルターを 5 行目のソケットにロードして接続しますが、3 行目と 4 行目では何が起こるでしょうか? これは、 libpcap 私たちの世話をします - フィルターの出力にそれを満たさないパケットが含まれないように、ライブラリ 接続します ダミーフィルター ret #0 (すべてのパケットをドロップ)、ソケットを非ブロッキング モードに切り替え、以前のフィルターから残っている可能性のあるすべてのパケットを減算しようとします。

まとめると、クラシック BPF を使用して Linux 上でパッケージをフィルタリングするには、次のような構造の形式のフィルタが必要です。 struct sock_fprog オープンソケット。その後、システムコールを使用してフィルターをソケットに接続できます。 setsockopt.

興味深いことに、フィルターは生だけでなく、あらゆるソケットに接続できます。 ここ 例 すべての受信 UDP データグラムから最初の XNUMX バイトを除くすべてを切り取るプログラム。 (記事が煩雑にならないように、コードにコメントを追加しました。)

ご利用について詳しくはこちら setsockopt フィルターの接続については、を参照してください。 ソケット（7）、ただし、次のような独自のフィルターを作成することについては、 struct sock_fprog 助けなしで tcpdump セクションで話します 自分の手でBPFをプログラミングする.

古典的な BPF と XNUMX 世紀

BPF は 1997 年に Linux に組み込まれ、長い間主力であり続けました。 libpcap 特別な変更はありません (もちろん Linux 固有の変更はあります) た、しかし世界的な状況は変わりませんでした）。 BPF が進化するという最初の深刻な兆候は、エリック デュマゼが提案した 2011 年に起こりました。 パッチこれにより、BPF バイトコードをネイティブに変換するトランスレーターである Just In Time Compiler がカーネルに追加されます。 x86_64 コード。

JIT コンパイラーは一連の変更の最初のものでした: 2012 年 出現した フィルタを作成する機能 セコンプ、BPF を使用して、2013 年 XNUMX 月に 追加されました モジュール xt_bpf、これにより、次のルールを作成できます。 iptables BPF の協力を得て、2013 年 XNUMX 月に 追加されました モジュールでもあります cls_bpfこれにより、BPF を使用してトラフィック分類子を作成できるようになります。

これらすべての例については後ほど詳しく見ていきますが、その前に、BPF 用の任意のプログラムを作成してコンパイルする方法を学習するのが役立ちます。ライブラリによって提供される機能があるためです。 libpcap 制限付き (簡単な例: フィルターが生成される) libpcap 0 つの値 - 0 または 40000xXNUMX のみを返すことができます）、または seccomp の場合のように、一般的には適用されません。

自分の手でBPFをプログラミングする

BPF 命令のバイナリ形式を理解しましょう。それは非常に簡単です。

   16    8    8     32
| code | jt | jf |  k  |

各命令は 64 ビットを占め、最初の 16 ビットが命令コードで、その後に XNUMX ビットのインデントが XNUMX つあります。 jt и jf、引数には 32 ビット K、その目的はコマンドごとに異なります。 たとえば、次のコマンドは ret、プログラムを終了するコードは次のとおりです 6、戻り値は定数から取得されます K。 C では、単一の BPF 命令は構造体として表されます。

struct sock_filter {
        __u16   code;
        __u8    jt;
        __u8    jf;
        __u32   k;
}

プログラム全体は構造体の形式になっています

struct sock_fprog {
        unsigned short len;
        struct sock_filter *filter;
}

したがって、私たちはすでにプログラムを書くことができます（たとえば、私たちは次の命令コードを知っています） 【1]）。 フィルターはこんな感じになります ip6 の 私たちの最初の例:

struct sock_filter code[] = {
        { 0x28, 0, 0, 0x0000000c },
        { 0x15, 0, 1, 0x000086dd },
        { 0x06, 0, 0, 0x00040000 },
        { 0x06, 0, 0, 0x00000000 },
};
struct sock_fprog prog = {
        .len = ARRAY_SIZE(code),
        .filter = code,
};

プログラム prog 通話中に合法的に使用できます

setsockopt(sk, SOL_SOCKET, SO_ATTACH_FILTER, &prog, sizeof(prog))

マシンコードの形式でプログラムを記述するのはあまり便利ではありませんが、場合によっては必要になります (たとえば、デバッグ、単体テストの作成、Habré に関する記事の執筆など)。 ファイル内の便宜上 <linux/filter.h> ヘルパー マクロが定義されています。上記と同じ例は次のように書き換えることができます。

struct sock_filter code[] = {
        BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 12),
        BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_IPV6, 0, 1),
        BPF_STMT(BPF_RET|BPF_K, 0x00040000),
        BPF_STMT(BPF_RET|BPF_K, 0),
}

ただし、このオプションはあまり便利ではありません。 これは、Linux カーネル プログラマが推論したものであり、したがって、 tools/bpf カーネルには、クラシック BPF を操作するためのアセンブラとデバッガが含まれています。

アセンブリ言語はデバッグ出力と非常に似ています tcpdumpですが、さらにシンボリックラベルを指定することもできます。 たとえば、TCP/IPv4 を除くすべてのパケットをドロップするプログラムを次に示します。

$ cat /tmp/tcp-over-ipv4.bpf
ldh [12]
jne #0x800, drop
ldb [23]
jneq #6, drop
ret #-1
drop: ret #0

デフォルトでは、アセンブラは次の形式でコードを生成します。 <количество инструкций>,<code1> <jt1> <jf1> <k1>,...、TCP の例では次のようになります。

$ tools/bpf/bpf_asm /tmp/tcp-over-ipv4.bpf
6,40 0 0 12,21 0 3 2048,48 0 0 23,21 0 1 6,6 0 0 4294967295,6 0 0 0,

C プログラマの便宜のために、別の出力形式を使用できます。

$ tools/bpf/bpf_asm -c /tmp/tcp-over-ipv4.bpf
{ 0x28,  0,  0, 0x0000000c },
{ 0x15,  0,  3, 0x00000800 },
{ 0x30,  0,  0, 0x00000017 },
{ 0x15,  0,  1, 0x00000006 },
{ 0x06,  0,  0, 0xffffffff },
{ 0x06,  0,  0, 0000000000 },

このテキストは型構造定義にコピーできます。 struct sock_filter、このセクションの冒頭で行ったように。

Linux および netsniff-ng 拡張機能

標準の BPF に加えて、Linux と tools/bpf/bpf_asm サポートと 非標準セット。 基本的に、命令は構造体のフィールドにアクセスするために使用されます。 struct sk_buff、カーネル内のネットワーク パケットを記述します。 ただし、他のタイプのヘルパー命令もあります。 ldw cpu レジスタにロードされます A カーネル関数の実行結果 raw_smp_processor_id()。 (BPF の新しいバージョンでは、これらの非標準拡張機能が拡張され、メモリ、構造体にアクセスし、イベントを生成するためのカーネル ヘルパーのセットをプログラムに提供します。) 以下は、フィルターの興味深い例です。拡張子を使用してパケットヘッダーをユーザー空間に送信します poff、ペイロード オフセット:

ld poff
ret a

BPF 拡張機能は次の場合には使用できません。 tcpdumpただし、これはユーティリティ パッケージについて知る十分な理由です。 netsniff-ng、特に高度なプログラムが含まれています netsniff-ngこれには、BPF を使用したフィルタリングに加えて、効果的なトラフィック ジェネレーターも含まれており、BPF よりも高度です。 tools/bpf/bpf_asmと呼ばれる BPF アセンブラ bpfc。 パッケージには非常に詳細なドキュメントが含まれています。記事の最後にあるリンクも参照してください。

セコンプ

したがって、任意の複雑さの BPF プログラムを作成する方法はすでに知っており、新しい例を検討する準備ができています。その最初の例は seccomp テクノロジーです。これにより、BPF フィルターを使用して、BPF プログラムで利用可能な一連のシステム コール引数を管理できます。特定のプロセスとその子孫。

seccomp の最初のバージョンは 2005 年にカーネルに追加されましたが、プロセスで使用できるシステム コールのセットを次のものに制限するという XNUMX つのオプションしか提供していなかったため、あまり人気がありませんでした。 read, write, exit и sigreturn、ルールに違反したプロセスは次の方法で強制終了されました。 SIGKILL。 ただし、2012 年に seccomp に BPF フィルターを使用する機能が追加され、許可されるシステム コールのセットを定義したり、その引数のチェックを実行したりできるようになりました。 (興味深いことに、Chrome はこの機能の最初のユーザーの XNUMX つであり、Chrome 担当者は現在、BPF の新しいバージョンに基づいて KRSI メカニズムを開発し、Linux セキュリティ モジュールのカスタマイズを可能にしています。) 追加のドキュメントへのリンクは最後にあります。記事の。

ハブには seccomp の使用に関する記事がすでに掲載されていることに注意してください。おそらく、次のサブセクションを読む前に (またはその代わりに) 読んでおきたい人もいるでしょう。 記事の中で コンテナとセキュリティ: seccomp 2007 バージョンと BPF を使用するバージョン (フィルターは libseccomp を使用して生成される) の両方の seccomp の使用例を示し、seccomp と Docker の接続について説明し、多くの役立つリンクも提供します。 記事の中で systemd でデーモンを分離するか、「これには Docker は必要ありません!」 特に、systemd を実行するデーモンのシステム コールのブラックリストまたはホワイトリストを追加する方法について説明します。

次に、フィルタを作成してロードする方法を見ていきます。 seccomp 裸のCでライブラリを使用する libseccomp そして、各オプションの長所と短所は何か、そして最後に、プログラムで seccomp がどのように使用されるかを見てみましょう。 strace.

seccomp のフィルターの作成とロード

BPF プログラムの作成方法はすでに理解しているので、まず seccomp プログラミング インターフェイスを見てみましょう。 プロセス レベルでフィルターを設定でき、すべての子プロセスが制限を継承します。 これはシステムコールを使用して行われます seccomp(2):

seccomp(SECCOMP_SET_MODE_FILTER, flags, &filter)

どこ &filter - これは私たちにすでに馴染みのある構造へのポインタです struct sock_fprog、つまりBPFプログラム。

seccomp のプログラムはソケットのプログラムとどう違うのですか? 送信されたコンテキスト。 ソケットの場合はパケットを含むメモリ領域が与えられ、seccomp の場合は次のような構造が与えられました。

struct seccomp_data {
    int   nr;
    __u32 arch;
    __u64 instruction_pointer;
    __u64 args[6];
};

それは nr は起動されるシステムコールの番号です。 arch - 現在のアーキテクチャ (詳細は後述)、 args - 最大 XNUMX つのシステムコール引数、および instruction_pointer システムコールを行ったユーザー空間命令へのポインタです。 したがって、たとえば、システムコール番号をレジスタにロードするには、 A 私たちは言わなければなりません

ldw [0]

seccomp プログラムには他にも機能があります。たとえば、コンテキストには 32 ビット アラインメントによってのみアクセスでき、フィルターをロードしようとする場合はハーフワードまたはバイトをロードできません。 ldh [0] システムコール seccomp 戻ります EINVAL。 この関数はロードされたフィルターをチェックします seccomp_check_filter() カーネル。 (面白いことに、seccomp 機能を追加した元のコミットでは、この関数に命令を使用する許可を追加するのを忘れていました。 mod (除算の余り) が追加されて以来、seccomp BPF プログラムでは使用できなくなりました。 壊れるだろう アビ。）

基本的に、私たちは seccomp プログラムを書いたり読んだりするためのすべてをすでに知っています。 通常、プログラム ロジックはシステム コールのホワイト リストまたはブラック リストとして構成されます。たとえば、

ld [0]
jeq #304, bad
jeq #176, bad
jeq #239, bad
jeq #279, bad
good: ret #0x7fff0000 /* SECCOMP_RET_ALLOW */
bad: ret #0

304、176、239、279 という番号が付いた XNUMX つのシステム コールのブラックリストをチェックします。これらのシステム コールは何ですか? プログラムがどのアーキテクチャ向けに書かれたのかがわからないため、確かなことは言えません。 したがって、seccomp の作成者は、 申し出 アーキテクチャ チェックを使用してすべてのプログラムを開始します (現在のアーキテクチャはコンテキスト内でフィールドとして示されます) arch 構造 struct seccomp_data）。 アーキテクチャをチェックすると、例の冒頭は次のようになります。

ld [4]
jne #0xc000003e, bad_arch ; SCMP_ARCH_X86_64

そして、システムコール番号は特定の値を取得します。

次を使用して seccomp のフィルターを作成してロードします。 libseccomp

ネイティブ コードまたは BPF アセンブリでフィルターを作成すると、結果を完全に制御できますが、同時に、移植性のあるコードや読み取り可能なコードを使用することが望ましい場合もあります。 図書館はこれを助けてくれます libseccomp、黒または白のフィルターを作成するための標準インターフェイスを提供します。

たとえば、システム コールのブラック リストを事前にインストールして、ユーザーが選択したバイナリ ファイルを実行するプログラムを作成してみましょう。 上の記事 (プログラムは読みやすくするために簡略化されています。完全版はこちらでご覧いただけます) ここで):

#include <seccomp.h>
#include <unistd.h>
#include <err.h>

static int sys_numbers[] = {
        __NR_mount,
        __NR_umount2,
       // ... еще 40 системных вызовов ...
        __NR_vmsplice,
        __NR_perf_event_open,
};

int main(int argc, char **argv)
{
        scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ALLOW);

        for (size_t i = 0; i < sizeof(sys_numbers)/sizeof(sys_numbers[0]); i++)
                seccomp_rule_add(ctx, SCMP_ACT_TRAP, sys_numbers[i], 0);

        seccomp_load(ctx);

        execvp(argv[1], &argv[1]);
        err(1, "execlp: %s", argv[1]);
}

まず配列を定義します sys_numbers ブロックする 40 以上のシステム コール番号。 次に、コンテキストを初期化します ctx そしてライブラリに何を許可したいかを伝えます(SCMP_ACT_ALLOW) デフォルトですべてのシステムコール (ブラックリストを作成する方が簡単です)。 次に、すべてのシステム コールをブラックリストに XNUMX つずつ追加します。 リストからのシステムコールに応答して、 SCMP_ACT_TRAP、この場合、seccomp はプロセスにシグナルを送信します。 SIGSYS どのシステムコールがルールに違反したかの説明付き。 最後に、次を使用してプログラムをカーネルにロードします。 seccomp_load、プログラムをコンパイルし、システム コールを使用してプロセスにアタッチします。 seccomp(2).

コンパイルを成功させるには、プログラムをライブラリにリンクする必要があります。 libseccompたとえば、次のようになります。

cc -std=c17 -Wall -Wextra -c -o seccomp_lib.o seccomp_lib.c
cc -o seccomp_lib seccomp_lib.o -lseccomp

成功した起動の例:

$ ./seccomp_lib echo ok
ok

ブロックされたシステム コールの例:

$ sudo ./seccomp_lib mount -t bpf bpf /tmp
Bad system call

を使用しております strace詳細については：

$ sudo strace -e seccomp ./seccomp_lib mount -t bpf bpf /tmp
seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=50, filter=0x55d8e78428e0}) = 0
--- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0xboobdeadbeef, si_syscall=__NR_mount, si_arch=AUDIT_ARCH_X86_64} ---
+++ killed by SIGSYS (core dumped) +++
Bad system call

不正なシステムコールの使用によりプログラムが終了したことをどのようにして知ることができますか? mount(2).

そこで、ライブラリを使用してフィルターを作成しました libseccomp、自明ではないコードを XNUMX 行に収めます。 上記の例では、多数のシステム コールがある場合、チェックは単なる比較のリストであるため、実行時間を大幅に短縮できます。 最適化のために、libseccomp には最近、 パッチ付属これにより、フィルター属性のサポートが追加されます。 SCMP_FLTATR_CTL_OPTIMIZE。 この属性を 2 に設定すると、フィルターがバイナリ検索プログラムに変換されます。

二分検索フィルターがどのように機能するかを確認したい場合は、以下を参照してください。 単純なスクリプト、システム コール番号をダイヤルすることにより、BPF アセンブラでそのようなプログラムを生成します。次に例を示します。

$ echo 1 3 6 8 13 | ./generate_bin_search_bpf.py
ld [0]
jeq #6, bad
jgt #6, check8
jeq #1, bad
jeq #3, bad
ret #0x7fff0000
check8:
jeq #8, bad
jeq #13, bad
ret #0x7fff0000
bad: ret #0

BPF プログラムはインデント ジャンプを実行できないため、大幅に高速に何かを書くことは不可能です (たとえば、私たちはそれができません) jmp A または jmp [label+X]) したがって、すべての遷移は静的です。

seccomp と strace

誰もがそのユーティリティを知っています strace Linux 上のプロセスの動作を研究するために不可欠なツールです。 しかし、多くの人が聞いたことがあるのは、 パフォーマンスの問題 このユーティリティを使用するとき。 事実は、 strace を使用して実装されました ptrace(2)そして、このメカニズムでは、どのシステムコールのセットでプロセスを停止する必要があるか、つまりコマンドなどを指定することはできません。

$ time strace du /usr/share/ >/dev/null 2>&1

real    0m3.081s
user    0m0.531s
sys     0m2.073s

и

$ time strace -e open du /usr/share/ >/dev/null 2>&1

real    0m2.404s
user    0m0.193s
sys     0m1.800s

はほぼ同時に処理されますが、XNUMX 番目のケースでは XNUMX つのシステム コールのみをトレースしたいと考えています。

新しいオプション --seccomp-bpfに追加 strace バージョン 5.3 では、プロセスを何倍にも高速化でき、XNUMX つのシステム コールのトレースでの起動時間はすでに通常の起動時間と同等になっています。

$ time strace --seccomp-bpf -e open du /usr/share/ >/dev/null 2>&1

real    0m0.148s
user    0m0.017s
sys     0m0.131s

$ time du /usr/share/ >/dev/null 2>&1

real    0m0.140s
user    0m0.024s
sys     0m0.116s

(もちろん、ここには、このコマンドのメイン システム コールをトレースしていないという点で、わずかな欺瞞があります。たとえば、トレースしていたとします。 newfsstatその後 strace ブレーキが無いのと同じくらい強くブレーキをかけるだろう --seccomp-bpf.)

このオプションはどのように機能するのでしょうか? 彼女なしで strace プロセスに接続し、それを使用してプロセスを開始します PTRACE_SYSCALL。 管理対象プロセスが (任意の) システム コールを発行すると、制御が次のプロセスに転送されます。 strace、システムコールの引数を調べ、それを使用して実行します。 PTRACE_SYSCALL。 しばらくすると、プロセスはシステム コールを完了し、終了すると制御が再び転送されます。 strace、戻り値を調べ、次を使用してプロセスを開始します。 PTRACE_SYSCALL、 等々。

ただし、seccomp を使用すると、このプロセスを希望どおりに最適化できます。 つまり、システムコールだけを見たい場合は、 Xそうすると、次のような BPF フィルターを書くことができます。 X 値を返します SECCOMP_RET_TRACE、および私たちにとって興味のない通話については、 SECCOMP_RET_ALLOW:

ld [0]
jneq #X, ignore
trace: ret #0x7ff00000
ignore: ret #0x7fff0000

この場合 strace 最初は次のようにプロセスを開始します PTRACE_CONT、システムコールがそうでない場合、フィルタはシステムコールごとに処理されます。 Xの場合、プロセスは引き続き実行されますが、これが X、その後、seccomp が制御を移します。 straceこれは引数を調べて次のようなプロセスを開始します PTRACE_SYSCALL (seccomp にはシステム コールの終了時にプログラムを実行する機能がないため)。 システムコールが返されると、 strace を使用してプロセスを再起動します PTRACE_CONT そして、seccomp からの新しいメッセージを待ちます。

オプション使用時 --seccomp-bpf 制限が XNUMX つあります。 まず、既存のプロセスに参加することはできません (オプション) -p プログラム strace)、これは seccomp でサポートされていないためです。 第二に、可能性はありません ノー 子プロセスに注目してください。これは、seccomp フィルタがすべての子プロセスに継承され、これを無効にする機能がないためです。

正確な方法についてもう少し詳しく説明すると、 strace で動作します seccomp から見つけることができます 最近の報告。 私たちにとって最も興味深い事実は、seccomp に代表される古典的な BPF が現在でも使用されていることです。

xt_bpf

さて、ネットワークの世界に戻りましょう。

背景: ずっと前の 2007 年、コアは 追加されました モジュール xt_u32 ネットフィルター用。 これは、さらに古いトラフィック分類子との類推によって作成されました。 cls_u32 また、パッケージから 32 ビットをロードし、それらに対して一連の算術演算を実行するという単純な操作を使用して、iptables の任意のバイナリ ルールを作成できるようになりました。 例えば、

sudo iptables -A INPUT -m u32 --u32 "6&0xFF=1" -j LOG --log-prefix "seen-by-xt_u32"

パディング 32 から始まる IP ヘッダーの 6 ビットをロードし、それらにマスクを適用します。 0xFF (下位バイトを取得します)。 このフィールド protocol IP ヘッダーを 1 (ICMP) と比較します。 XNUMX つのルールに多くのチェックを結合でき、演算子を実行することもできます。 @ — X バイトを右に移動します。 たとえば、次のようなルールがあります。

iptables -m u32 --u32 "6&0xFF=0x6 && 0>>22&0x3C@4=0x29"

TCP シーケンス番号が等しくないかどうかを確認します 0x29。 このようなルールを手書きするのはあまり便利ではないことはすでに明らかであるため、これ以上詳しくは説明しません。 記事の中で BPF - 忘れられたバイトコード、使用例とルール生成の例を示したリンクがいくつかあります。 xt_u32。 この記事の最後にあるリンクも参照してください。

2013 年以降、モジュールの代わりにモジュールになりました xt_u32 BPFベースのモジュールを使用できます xt_bpf。 ここまで読んだ人なら、BPF バイトコードを iptables ルールとして実行するという動作原理をすでに理解しているはずです。 たとえば、次のように新しいルールを作成できます。

iptables -A INPUT -m bpf --bytecode <байткод> -j LOG

ここで <байткод> - これはアセンブラ出力形式のコードです bpf_asm デフォルトでは、たとえば、

$ cat /tmp/test.bpf
ldb [9]
jneq #17, ignore
ret #1
ignore: ret #0

$ bpf_asm /tmp/test.bpf
4,48 0 0 9,21 0 1 17,6 0 0 1,6 0 0 0,

# iptables -A INPUT -m bpf --bytecode "$(bpf_asm /tmp/test.bpf)" -j LOG

この例では、すべての UDP パケットをフィルタリングしています。 モジュール内の BPF プログラムのコンテキスト xt_bpfもちろん、iptables の場合はパケット データ、IPv4 ヘッダーの先頭を指します。 BPF プログラムからの戻り値 ブール値どこ false パケットが一致しなかったことを意味します。

モジュールであることは明らかです xt_bpf は、上記の例よりも複雑なフィルターをサポートしています。 Cloudfare の実例を見て​​みましょう。 最近まで彼らはモジュールを使用していました xt_bpf DDoS 攻撃から保護します。 記事の中で BPF ツールの紹介 BPF フィルターを生成する方法 (およびその理由) を説明し、そのようなフィルターを作成するための一連のユーティリティへのリンクを公開します。 たとえば、ユーティリティを使用すると、 bpfgen DNS クエリと名前を照合する BPF プログラムを作成できます。 habr.com:

$ ./bpfgen --assembly dns -- habr.com
ldx 4*([0]&0xf)
ld #20
add x
tax

lb_0:
    ld [x + 0]
    jneq #0x04686162, lb_1
    ld [x + 4]
    jneq #0x7203636f, lb_1
    ldh [x + 8]
    jneq #0x6d00, lb_1
    ret #65535

lb_1:
    ret #0

プログラムでは、まずレジスタにロードします。 X 行頭アドレス x04habrx03comx00 UDP データグラム内でリクエストを確認します。 0x04686162 <-> "x04hab" 等

少し後に、Cloudfare が p0f -> BPF コンパイラ コードを公開しました。 記事の中で p0f BPF コンパイラの紹介 彼らは、p0f とは何か、および p0f 署名を BPF に変換する方法について話します。

$ ./bpfgen p0f -- 4:64:0:0:*,0::ack+:0
39,0 0 0 0,48 0 0 8,37 35 0 64,37 0 34 29,48 0 0 0,
84 0 0 15,21 0 31 5,48 0 0 9,21 0 29 6,40 0 0 6,
...

現在はクラウドフェアを使用していません xt_bpf、新しいバージョンの BPF を使用するためのオプションの XNUMX つである XDP に移行したため、を参照してください。 L4Drop: XDP DDoS 軽減策.

cls_bpf

カーネル内でクラシック BPF を使用する最後の例は、分類子です。 cls_bpf Linux のトラフィック制御サブシステム用。2013 年末に Linux に追加され、概念的に古代のサブシステムを置き換えます。 cls_u32.

ただし、この作品についてはここでは説明しません cls_bpfなぜなら、古典的な BPF に関する知識の観点からは、これは私たちに何も得られないからです。私たちはすでにすべての機能に精通しています。 さらに、拡張 BPF について説明する後続の記事では、この分類子を複数回取り上げます。

古典的な BPF c の使用について話さないもう XNUMX つの理由 cls_bpf 問題は、拡張 BPF と比較して、この場合の適用範囲が大幅に狭まっていることです。従来のプログラムはパッケージの内容を変更できず、呼び出し間の状態を保存できません。

したがって、古典的な BPF に別れを告げ、未来に目を向ける時が来ました。

古典的な BPF に別れを告げる

私たちは、32 年代初頭に開発された BPF テクノロジーが四半世紀にわたってどのように生き続け、最後まで新たな用途を見つけたのかを調べました。 しかし、クラシック BPF 開発のきっかけとなったスタック マシンから RISC への移行と同様に、64 年代には XNUMX ビット マシンから XNUMX ビット マシンへの移行があり、クラシック BPF は時代遅れになり始めました。 さらに、クラシック BPF の機能は非常に限られており、アーキテクチャが古いことに加えて、BPF プログラムの呼び出しの間に状態を保存する機能がなく、ユーザーとの直接対話の可能性がなく、相互作用する可能性もありません。限られた数の構造体フィールドの読み取りを除き、カーネルを使用 sk_buff 最も単純なヘルパー関数を起動する場合、パケットの内容を変更したり、パケットをリダイレクトしたりすることはできません。

実際、現在、Linux のクラシック BPF に残っているのは API インターフェイスだけであり、カーネル内では、ソケット フィルターであっても seccomp フィルターであっても、すべてのクラシック プログラムは新しい形式である拡張 BPF に自動的に変換されます。 (これがどのように起こるのかについては、次の記事で詳しく説明します。)

新しいアーキテクチャへの移行は、Alexey Starovoitov が BPF 更新スキームを提案した 2013 年に始まりました。 2014 年に対応するパッチ 現れ始めた 核心にある。 私の理解する限り、当初の計画は 64 ビット マシンでより効率的に実行できるようにアーキテクチャと JIT コンパイラを最適化することだけでしたが、代わりにこれらの最適化が Linux 開発の新しい章の始まりとなりました。

このシリーズの今後の記事では、当初は内部 BPF、その後拡張 BPF、そして現在は単に BPF として知られている新しいテクノロジーのアーキテクチャとアプリケーションについて説明します。

リファレンス

1. Steven McCanne および Van Jacobson、「BSD パケット フィルター: ユーザーレベルのパケット キャプチャのための新しいアーキテクチャ」、 https://www.tcpdump.org/papers/bpf-usenix93.pdf
2. Steven McCanne、「libpcap: パケット キャプチャのためのアーキテクチャと最適化方法論」、 https://sharkfestus.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf
3. tcpdump, libpcap: https://www.tcpdump.org/
4. IPtable U32 マッチのチュートリアル.
5. BPF - 忘れられたバイトコード: https://blog.cloudflare.com/bpf-the-forgotten-bytecode/
6. BPF ツールの紹介: https://blog.cloudflare.com/introducing-the-bpf-tools/
7. bpf_cls: http://man7.org/linux/man-pages/man8/tc-bpf.8.html
8. seccomp の概要: https://lwn.net/Articles/656307/
9. https://github.com/torvalds/linux/blob/master/Documentation/userspace-api/seccomp_filter.rst
10. habr: コンテナとセキュリティ: seccomp
11. habr: systemd でデーモンを分離する、または「これには Docker は必要ありません!」
12. Paul Chaignon、「strace --seccomp-bpf: 内部の様子」、 https://fosdem.org/2020/schedule/event/debugging_strace_bpf/
13. netsniff-ng: http://netsniff-ng.org/

出所： habr.com