執筆者：稲葉貴昭
1. はじめに
前回の概論編では、eBPF（以下、BPFと表記）がどんなものでどのように実現されているかを中心に解説いたしました。 また、BCCやBCC-Tools、CO-REについての解説も行いました。 実装編となる今回は、BCC-Toolsの後継となるlibbpf-toolsよりopensnoopコマンドに着目して ソースコードレベルの解説を行います。
2. 使用環境
BPFは、2022年8月現在も活発に開発が進められているため、理由がなければ新しいカーネルバージョンを使ったほうがいいです。
特にCO-REについては、libbpfのバージョンの関係でUbuntuだと20.10以降にする必要があります。
今回の調査は、最新のLTS版であるUbuntu 22.04 LTSを使用しました。
調査を行ったのは、執筆時点で最新のバージョンだったBCC v0.24.0です。*1
libbpf-toolsのリポジトリを見ると*.bpf.cと*.cというファイルが大量にあることがわかります。
ファイル名が「*.bpf.c」となっているのは、前回の記事におけるBPFプログラムに当たります。
また、ファイル名が「*.c」になっているのは、前回の記事におけるBPFアプリケーションになります。
さて、本記事ではこれらコマンドの中からopensnoopというコマンドの解説を軸にします。 ただし、すべてのコードについて解説をいれると相当な量になるため、筆者がポイントになっていると感じた箇所のみ解説する形にいたします。
3. コンパイル
以下の手順でcloneとコンパイルができます。
sudo apt install make gcc libelf-dev clang llvm git clone https://github.com/iovisor/bcc.git cd bcc git checkout -b v0.24.0 refs/tags/v0.24.0 git submodule update --init --recursive cd libbpf-tools make
4. opensnoopとは
opensnoopは、openシステムコール
が呼ばれた際に、どのプロセスがどのファイルをopenしたのかをトレースするためのコマンドです。
usageは以下のようになっています。
Usage: opensnoop [OPTION...]
Trace open family syscalls
USAGE: opensnoop [-h] [-T] [-U] [-x] [-p PID] [-t TID] [-u UID] [-d DURATION]
[-n NAME] [-e]
EXAMPLES:
./opensnoop # trace all open() syscalls
./opensnoop -T # include timestamps
./opensnoop -U # include UID
./opensnoop -x # only show failed opens
./opensnoop -p 181 # only trace PID 181
./opensnoop -t 123 # only trace TID 123
./opensnoop -u 1000 # only trace UID 1000
./opensnoop -d 10 # trace for 10 seconds only
./opensnoop -n main # only print process names containing "main"
./opensnoop -e # show extended fields
-d, --duration=DURATION Duration to trace
-e, --extended-fields Print extended fields
-n, --name=NAME Trace process names containing this
-p, --pid=PID Process ID to trace
-t, --tid=TID Thread ID to trace
-T, --timestamp Print timestamp
-u, --uid=UID User ID to trace
-U, --print-uid Print UID
-v, --verbose Verbose debug output
-x, --failed Failed opens only
-?, --help Give this help list
--usage Give a short usage message
-V, --version Print program version
以下はオプション指定なしで実行したときの出力結果です。
実行には管理者権限が必要になります。
左から、「openを呼んだプロセスID」、「プロセス名」、「openの戻り値であるファイルディスクリプタ」、
「errno」、「openしたファイルパス」となっています。
PID COMM FD ERR PATH 2870 systemd-journal 39 0 /proc/618498/comm 2870 systemd-journal 39 0 /proc/618498/cmdline ... 618500 opensnoop 24 0 /etc/localtime 2870 systemd-journal 39 0 /proc/618498/loginuid 2870 systemd-journal 39 0 /proc/618498/cgroup ... 67345 tmux: server 9 0 /proc/618498/cmdline 24927 irqbalance 6 0 /proc/interrupts
5. opensnoop.bpf.cの解説
opensnoop.bpf.cは、opensnoopにおけるBPFプログラムにあたる部分です。
5.1 mapの宣言
10 const volatile __u64 min_us = 0; 11 const volatile pid_t targ_pid = 0; 12 const volatile pid_t targ_tgid = 0; 13 const volatile uid_t targ_uid = 0; 14 const volatile bool targ_failed = false; 15 16 struct { 17 __uint(type, BPF_MAP_TYPE_HASH); 18 __uint(max_entries, 10240); 19 __type(key, u32); 20 __type(value, struct args_t); 21 } start SEC(".maps"); 22 23 struct { 24 __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY); 25 __uint(key_size, sizeof(u32)); 26 __uint(value_size, sizeof(u32)); 27 } events SEC(".maps");
ここでは、mapの宣言を行っているのですが、BPF特有のC言語の書き方になっています。
まず、先頭4行の変数ですが、これらはopensnoopの-p/-t/-u/-fオプションを指定するときに使用されるものです。
例えば、-pオプションは引数で指定したプロセスIDがopenシステムコールを呼んだ時のみ出力するオプションなので、
BPFアプリケーションの引数解析処理が終わった後で引数指定したプロセスIDがセットされます。
C言語を知っている人からすれば、「constで宣言しているのに後で書き換える？」、「コンパイル単位が違うプログラムで
値を書き換える？」と思われるかもしれません。
この辺の疑問はBPFアプリケーションの解説時に後述するので、ここでは「constで宣言しているからrodataセクションに配置」
されるということだけご認識ください。
下の2つの構造体は、mapの宣言になります。
startは、プロセスIDをkeyに、openシステムコールに渡しているfilename、flagsをvalueにした最大エントリ数10240のhash mapで、
引数を一時的に格納するために使用されます。
eventsは、BPFプログラムの処理結果をBPFアプリケーション側と共有するためのものです。
SEC()は指定したセクションに変数を配置するためのマクロです。 SEC(".maps")となっているので、ELFの.mapセクションに配置されることになります。
5.2 BPFプログラムのメイン処理
ここからは、opensnoop.bpf.cのメイン処理です。 opensnoopは、openシステムコールとopenatシステムコールの両方をトレースしているのですが、 やっていることは同じなので本記事ではopenに関する部分のみ解説します。
33 static __always_inline 34 bool trace_allowed(u32 tgid, u32 pid) 35 { 36 u32 uid; 37 38 /* filters */ 39 if (targ_tgid && targ_tgid != tgid) 40 return false; 41 if (targ_pid && targ_pid != pid) 42 return false; 43 if (valid_uid(targ_uid)) { 44 uid = (u32)bpf_get_current_uid_gid(); 45 if (targ_uid != uid) { 46 return false; 47 } 48 } 49 return true; 50 } 51 52 SEC("tracepoint/syscalls/sys_enter_open") 53 int tracepoint__syscalls__sys_enter_open(struct trace_event_raw_sys_enter* ctx) 54 { 55 u64 id = bpf_get_current_pid_tgid(); 56 /* use kernel terminology here for tgid/pid: */ 57 u32 tgid = id >> 32; 58 u32 pid = id; 59 60 /* store arg info for later lookup */ 61 if (trace_allowed(tgid, pid)) { 62 struct args_t args = {}; 63 args.fname = (const char *)ctx->args[0]; 64 args.flags = (int)ctx->args[1]; 65 bpf_map_update_elem(&start, &pid, &args, 0); 66 } 67 return 0; 68 } .... 88 static __always_inline 89 int trace_exit(struct trace_event_raw_sys_exit* ctx) 90 { 91 struct event event = {}; 92 struct args_t *ap; 93 int ret; 94 u32 pid = bpf_get_current_pid_tgid(); 95 96 ap = bpf_map_lookup_elem(&start, &pid); 97 if (!ap) 98 return 0; /* missed entry */ 99 ret = ctx->ret; 100 if (targ_failed && ret >= 0) 101 goto cleanup; /* want failed only */ 102 103 /* event data */ 104 event.pid = bpf_get_current_pid_tgid() >> 32; 105 event.uid = bpf_get_current_uid_gid(); 106 bpf_get_current_comm(&event.comm, sizeof(event.comm)); 107 bpf_probe_read_user_str(&event.fname, sizeof(event.fname), ap->fname); 108 event.flags = ap->flags; 109 event.ret = ret; 110 111 /* emit event */ 112 bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, 113 &event, sizeof(event)); 114 115 cleanup: 116 bpf_map_delete_elem(&start, &pid); 117 return 0; 118 } 119 120 SEC("tracepoint/syscalls/sys_exit_open") 121 int tracepoint__syscalls__sys_exit_open(struct trace_event_raw_sys_exit* ctx) 122 { 123 return trace_exit(ctx); 124 }
5.2.1 33-68行目
tracepoint__syscalls__sys_enter_openは、openシステムコールの呼び出しをイベントとして呼ばれる関数です。
55行目のbpf_get_current_pid_tgidはBPFヘルパー関数の１つで、呼び出した時点でのプロセスのスレッドIDとプロセスIDをカーネルが持つデータ構造から取得します。
処理の実体は、カーネル内に存在しています。
trace_allowedを使って判定（61行目）し、トレース対象であればopenシステムコールの引数であるファイル名とフラグをBPFヘルパー関数の
bpf_map_update_elemを使ってmapに格納します。
5.2.2 88-124行目
tracepoint__syscalls__sys_exit_openは、openシステムコールが終了するときに呼ばれる関数です。
trace_exitでは、tracepoint__syscalls__sys_enter_openでmapに格納したデータを取り出し（96行目）、
さらにBPFアプリケーション側で必要になる情報をevent構造体にコピーしています（104-109行目）。
最終的に、BPFヘルパー関数であるbpf_perf_event_outputを呼び出し、BPFアプリケーションからデータが読みだせるようにします。
5.2.3 プログラムタイプとコンテキスト
BPFプログラムが呼ばれたときにカーネル側から渡される引数のことをコンテキストと呼びます。
tracepoint__syscalls__sys_exit_openとtracepoint__syscalls__sys_enter_openに渡されているctxがそれにあたります。
このコンテキストですが、何が渡されるかはプログラムタイプによって決まります。
プログラムタイプは、ユーザが作成したBPFプログラムの種別を表すもので、
カーネル内に定義値があり、BPFアプリケーションでBPFプログラムをロードする際に指定する必要があります。
プログラムタイプは、BPFプログラムから呼び出せるBPFヘルパー関数の種類や、そもそもどのタイミングでBPFプログラムがカーネルから呼ばれるかにも影響します。
プログラムタイプごとに呼び出し可能なBPFヘルパー関数は、BCCのドキュメントにまとめられています。
BPFアプリケーションがどのようにプログラムタイプを指定しているのかは後述しますが、先に結論を
書くとopensnoopは「BPF_PROG_TYPE_TRACEPOINT」を使用しています。
opensnoopのようにシステムコールに対して「BPF_PROG_TYPE_TRACEPOINT」を指定した場合、
BPFプログラムに渡されるコンテキストは以下のコマンドで調べることができます。
また、sys_exit_openに渡されるコンテキストは、sys_enter_openの部分をsys_exit_openに変更することで調べられます。
sudo cat /sys/kernel/debug/tracing/events/syscalls/sys_enter_open/format
5.3 opensnoop.bpf.cのコンパイル
「make opensnoop」と実行すると、以下の流れでopensnoopの実行形式ファイルが生成されます。
clang -g -O2 -Wall -target bpf -D__TARGET_ARCH_x86 -Ix86/ -I.output -I../src/cc/libbpf/include/uapi -c opensnoop.bpf.c -o .output/opensnoop.bpf.o && llvm-strip -g .output/opensnoop.bpf.o bin/bpftool gen skeleton .output/opensnoop.bpf.o > .output/opensnoop.skel.h cc -g -O2 -Wall -I.output -I../src/cc/libbpf/include/uapi -c opensnoop.c -o .output/opensnoop.o cc -g -O2 -Wall .output/opensnoop.o bcc/libbpf-tools/.output/libbpf.a .output/trace_helpers.o .output/syscall_helpers.o .output/errno_helpers.o .output/map_helpers.o .output/uprobe_helpers.o -lelf -lz -o opensnoop
1行目は、Clang/LLVMでopensnoop.bpf.cをBPFバイトコードとしてコンパイルしています。
2行目は、bpftoolというBPFの開発ツールを使って、opensnoop.bpf.oからopensnoop.skel.hというヘッダファイルを
生成しています。この*.skel.hというのは、スケルトンヘッダと言われopensnoop.bpf.oの骨組みを抽出したものになります。
3行目でopensnoop.cをコンパイルし、4行目でlibbpfなどとリンクしてopensnoopが完成します。
BPFプログラムはカーネルにロードする必要があるため、opensnoop自体にリンクはされていません。
BPFアプリケーション（opensnoop.c）がどうやってBPFプログラムを読み込むかは、2行目で生成されるスケルトンヘッダ
が関係しています。
6. opensnoop.cの解説
opensnoop.cは、opensnoopにおけるBPFアプリケーションにあたる部分です。
6.1、6.2章でBPFアプリケーションのメイン処理であるopensnoop.cの自体の解説を行い、
以降はメイン処理から呼ばれる各種処理について深追いしていきます。
自動生成のスケルトン部分とlibbpf内部の関数が入り乱れてしまいますが、
見分け方としては関数名が「opensnoop_」で始まるものがスケルトンヘッダ内に存在しているもので、
「bpf_」で始まるものがlibbpf内に存在しているものになります。
6.1 ヘッダファイルのインクルード
17 #include "opensnoop.h" 18 #include "opensnoop.skel.h" 19 #include "trace_helpers.h"
17行目でBPFプログラムと共有する構造体が定義されているopensnoop.hをインクルードしています。
また、18行目でBPFプログラムを使って自動生成したスケルトンヘッダをインクルードすることで、
スケルトンヘッダ内のバイトコードをメモリに読み込みます。
6.2 BPFアプリケーションのメイン処理
BPFアプリケーションのメイン処理は以下のようになっています。 処理概要としては以下のようになっています。
opensnoop_bpf__open：スケルトンヘッダの読み込み、各種構造体の実体化、プログラムタイプの設定opensnoop_bpf__load：mapの作成、BPFプログラムのカーネルへのロードopensnoop_bpf__attach：BPFプログラムをイベントにアタッチperf_buffer__poll：BPFプログラムがmapに書き込みをしたことを契機にハンドラを実行
215 int main(int argc, char **argv) 216 { ... 231 libbpf_set_strict_mode(LIBBPF_STRICT_ALL); 232 libbpf_set_print(libbpf_print_fn); 233 234 obj = opensnoop_bpf__open(); ... 241 obj->rodata->targ_tgid = env.pid; 242 obj->rodata->targ_pid = env.tid; 243 obj->rodata->targ_uid = env.uid; 244 obj->rodata->targ_failed = env.failed; ... 256 err = opensnoop_bpf__load(obj); ... 262 err = opensnoop_bpf__attach(obj); ... 278 /* setup event callbacks */ 279 pb = perf_buffer__new(bpf_map__fd(obj->maps.events), PERF_BUFFER_PAGES, 280 handle_event, handle_lost_events, NULL, NULL); ... 297 /* main: poll */ 298 while (!exiting) { 299 err = perf_buffer__poll(pb, PERF_POLL_TIMEOUT_MS); ... 308 } ... 315 }
6.3 231-232行目
231行目のlibbpf_set_strict_modeは、近い将来行われるlibbpfの大規模変更にあらかじめ適合するためのものです。 libbpfは2022年8月現在の最新版がv0.8.1ですが、v1.0では大規模な変更が行われるとアナウンスされています。
232行目は、opensnoopの出力関数の差し替えを行っています。 libbpf_print_fnは、vfprintfを使い標準エラー出力に出力しています。
6.4 opensnoop_bpf__open
opensnoop_bpf__openは、スケルトンヘッダの読み込み、各種構造体の実体化、プログラムタイプの設定など様々な処理を行い、opensnoop_bpf構造体を構築します。
opensnoop_bpf構造体の定義はopensnoop.skel.hにあります。
11 struct opensnoop_bpf { 12 struct bpf_object_skeleton *skeleton; 13 struct bpf_object *obj; 14 struct { 15 struct bpf_map *start; 16 struct bpf_map *events; 17 struct bpf_map *rodata; 18 } maps; 19 struct { 20 struct bpf_program *tracepoint__syscalls__sys_enter_open; 21 struct bpf_program *tracepoint__syscalls__sys_enter_openat; 22 struct bpf_program *tracepoint__syscalls__sys_exit_open; 23 struct bpf_program *tracepoint__syscalls__sys_exit_openat; 24 } progs; 25 struct { 26 struct bpf_link *tracepoint__syscalls__sys_enter_open; 27 struct bpf_link *tracepoint__syscalls__sys_enter_openat; 28 struct bpf_link *tracepoint__syscalls__sys_exit_open; 29 struct bpf_link *tracepoint__syscalls__sys_exit_openat; 30 } links; 31 struct opensnoop_bpf__rodata { 32 __u64 min_us; 33 pid_t targ_pid; 34 pid_t targ_tgid; 35 uid_t targ_uid; 36 bool targ_failed; 37 } *rodata; 38 };
前述の通り、スケルトンヘッダはbpftoolによりBPFプログラムから自動生成されるものであるため、構造体メンバの名前の多くがBPFプログラムで設定したものになっています。
それぞれのメンバの役割は必要に応じて後述しますが、opensnoop_bpf__openは、opensnoop_bpf構造体を作成して、値をセットするのがひとつの役割になっています。
opensnoop_bpf__openは、以下のようにopensnoop_bpf__open_optsを呼び出すだけです。
53 static inline struct opensnoop_bpf * 54 opensnoop_bpf__open_opts(const struct bpf_object_open_opts *opts) 55 { ... 59 obj = (struct opensnoop_bpf *)calloc(1, sizeof(*obj)); ... 65 err = opensnoop_bpf__create_skeleton(obj); ... 69 err = bpf_object__open_skeleton(obj->skeleton, opts); ... 78 } 79 80 static inline struct opensnoop_bpf * 81 opensnoop_bpf__open(void) 82 { 83 return opensnoop_bpf__open_opts(NULL); 84 }
59行目でopensnoop_bpf構造体をアロケートし、65行目でopensnoop_bpf__create_skeletonを呼び出し、スケルトン構造体を構築します。
opensnoop_bpf__create_skeletonは以下のようになっています。
124 static inline int 125 opensnoop_bpf__create_skeleton(struct opensnoop_bpf *obj) 126 { 127 struct bpf_object_skeleton *s; 128 129 s = (struct bpf_object_skeleton *)calloc(1, sizeof(*s)); 130 if (!s) 131 goto err; 132 obj->skeleton = s; 133 134 s->sz = sizeof(*s); 135 s->name = "opensnoop_bpf"; 136 s->obj = &obj->obj; 137 138 /* maps */ 139 s->map_cnt = 3; 140 s->map_skel_sz = sizeof(*s->maps); 141 s->maps = (struct bpf_map_skeleton *)calloc(s->map_cnt, s->map_skel_sz); 142 if (!s->maps) 143 goto err; 144 145 s->maps[0].name = "start"; 146 s->maps[0].map = &obj->maps.start; 147 148 s->maps[1].name = "events"; 149 s->maps[1].map = &obj->maps.events; 150 151 s->maps[2].name = "opensnoo.rodata"; 152 s->maps[2].map = &obj->maps.rodata; 153 s->maps[2].mmaped = (void **)&obj->rodata; ... 158 s->progs = (struct bpf_prog_skeleton *)calloc(s->prog_cnt, s->prog_skel_sz); 159 if (!s->progs) 160 goto err; 161 162 s->progs[0].name = "tracepoint__syscalls__sys_enter_open"; 163 s->progs[0].prog = &obj->progs.tracepoint__syscalls__sys_enter_open; 164 s->progs[0].link = &obj->links.tracepoint__syscalls__sys_enter_open; ... 170 s->progs[2].name = "tracepoint__syscalls__sys_exit_open"; 171 s->progs[2].prog = &obj->progs.tracepoint__syscalls__sys_exit_open; 172 s->progs[2].link = &obj->links.tracepoint__syscalls__sys_exit_open; ... 178 s->data = (void *)opensnoop_bpf__elf_bytes(&s->data_sz); ... 186 static inline const void *opensnoop_bpf__elf_bytes(size_t *sz) 187 { 188 *sz = 12752; 189 return (const void *) " 190 \x7f\x45\x4c\x46\x02\x01\x01\0\0\0\0\0\0\0\0\0\x01\0\xf7\0\x01\0\0\0\0\0\0\0\0\ 191 \0\0\0\0\0\0\0\0\0\0\0\xd0\x2c\0\0\0\0\0\0\0\0\0\0\x40\0\0\0\0\0\x40\0\x14\0\ 192 \x01\0\xbf\x16\0\0\0\0\0\0\x85\0\0\0\x0e\0\0\0\x63\x0a\xfc\xff\0\0\0\0\x18\x01\
opensnoop_bpf__elf_bytesでreturnしているバイト列がBPFプログラムのバイトコードになります。
後の工程でこのELFバイナリをlibelfで解析して、必要な構造体に移し替えたりして最終的に
カーネルにロードするような構造になっています。
opensnoopのリンクで-lelfを指定しているのはそのためです。
さて、opensnoop_bpf__create_skeletonを呼び出した結果、opensnoop_bpf構造体は図1のようになります。
図１の通り、bpf_object_skeleton構造体の中身はほとんどがopensnoop_bpf構造体への参照になっていますが、 これは以降の工程でlibbpfの処理に入っていくため、opensnoop_bpf構造体というopensnoopに特化した構造体からbpf_object_skeleton構造体という汎用的な構造体へデータを関連付けるためです。
bpf_object__open_skeletonは、以下のようになっています。
6957 static struct bpf_object *bpf_object_open(const char *path, const void *obj_buf, size_t obj_buf_sz, 6958 const struct bpf_object_open_opts *opts) 6959 { ... 6997 obj = bpf_object__new(path, obj_buf, obj_buf_sz, obj_name); ... 7032 err = err ? : bpf_object__init_maps(obj, opts); 7033 err = err ? : bpf_object_init_progs(obj, opts); ... 7044 } ... 7087 struct bpf_object * 7088 bpf_object__open_mem(const void *obj_buf, size_t obj_buf_sz, 7089 const struct bpf_object_open_opts *opts) 7090 { ... 7094 return libbpf_ptr(bpf_object_open(NULL, obj_buf, obj_buf_sz, opts)); 7095 } ... 11643 int bpf_object__open_skeleton(struct bpf_object_skeleton *s, 11644 const struct bpf_object_open_opts *opts) 11645 { ... 11664 obj = bpf_object__open_mem(s->data, s->data_sz, &skel_opts); ... 11672 *s->obj = obj; ... 11699 } ...
libbpfの中はコード量が多いため、解説を行わない箇所は大胆に割愛しています。
bpf_object__open_skeletonは、
bpf_object__open_mem→bpf_object_openを呼びbpf_object構造体を作成します。
bpf_object構造体は、最終的にはbpfシステムコールを呼ぶときにカーネルに渡す引数を含んでいる重要な構造体です。
11672行目で、opensnoop_bpf構造体から参照できるようにセットされています。
6997行目のbpf_object__newではbpf_object構造体をアロケートとopensnoop.bpf.oのELFバイナリのバイト列の参照のセットなどを行っています。
6.4.1 bpf_object__init_maps
7032行目のbpf_object__init_mapsでは、mapの初期化の過程でBPFプログラム内のSEC(".maps")を使って宣言した変数に対する処理を以下の流れで行っています。
bpf_object__init_maps→bpf_object__init_user_btf_maps→bpf_object__init_user_btf_map→parse_btf_map_def
最終的には、BPFプログラム内で宣言したstartやeventsは、bpf_object構造体のmaps配列に格納され、後工程でbpfシステムコールを呼んでmapを作成する際に使われます。
また、以下の流れでBPFプログラム内でconst付きで宣言していたグローバル変数に関する処理も行っています。
bpf_object__init_maps→bpf_object__init_global_data_maps→bpf_object__init_internal_map
BPFプログラム内でグローバル変数に代入していた初期値は、1579行目でmmapシステムコールで確保した領域にコピーされています。
6.4.2 bpf_object_init_progs
6931行目でカーネルにロードするプログラムのプログラムタイプをセットしています。
前述の通り、opensnoopは「BPF_PROG_TYPE_TRACEPOINT」をセットするわけですが、
これは実はBPFプログラム内にあるSEC("tracepoint/syscalls/sys_enter_open")という指定方法が関係しています。
6923行目のfind_sec_defでは、以下のsection_defsテーブルを探索しセクション名がsection_defsテーブルに指定した文字列リテラルと一致するオブジェクトを探索しています。 その結果、以下のテーブルの8585行目に一致し、prog->sec_def->prog_typeが「BPF_PROG_TYPE_TRACEPOINT」になるというわけです。
8558 #define SEC_DEF(sec_pfx, ptype, atype, flags, ...) { \ 8559 .sec = sec_pfx, \ 8560 .prog_type = BPF_PROG_TYPE_##ptype, \ 8561 .expected_attach_type = atype, \ 8562 .cookie = (long)(flags), \ 8563 .preload_fn = libbpf_preload_prog, \ 8564 __VA_ARGS__ \ 8565 } ... 8574 static const struct bpf_sec_def section_defs[] = { 8575 SEC_DEF("socket", SOCKET_FILTER, 0, SEC_NONE | SEC_SLOPPY_PFX), ... 8578 SEC_DEF("kprobe/", KPROBE, 0, SEC_NONE, attach_kprobe), 8579 SEC_DEF("uprobe/", KPROBE, 0, SEC_NONE), 8580 SEC_DEF("kretprobe/", KPROBE, 0, SEC_NONE, attach_kprobe), 8581 SEC_DEF("uretprobe/", KPROBE, 0, SEC_NONE), ... 8585 SEC_DEF("tracepoint/", TRACEPOINT, 0, SEC_NONE, attach_tp), 8586 SEC_DEF("tp/", TRACEPOINT, 0, SEC_NONE, attach_tp), ...
6.5 241-245行目
ユーザが引数で指定したフィルタのオプション値を代入しています。
BPFプログラム内でtarg_tgidやtarg_pidなどを参照していますが、最終的にはここで設定した値を参照しています。
BPFプログラムのコンパイル単位では、const付きで宣言していたので変更不可ですが
obj->rodataで参照するのは、bpf_object__init_internal_map内でmmapが確保した領域になっているため、変更ができるというわけです。
ただグローバル変数の変更が有効なのはopensnoop_bpf__open後、opensnoop_bpf__load前の区間だけになります。
opensnoop_bpf__load以降は、BPFプログラムはカーネルにロードされるため、BPFプログラム内で参照している変数の変更ができないためです。
6.6 opensnoop_bpf__load
opensnoop_bpf__loadは、スケルトンヘッダファイルの中に処理がありますが、
やっていることは以下のようにlibbpfのbpf_object__load_skeletonを呼ぶだけです。
86 static inline int 87 opensnoop_bpf__load(struct opensnoop_bpf *obj) 88 { 89 return bpf_object__load_skeleton(obj->skeleton); 90 }
bpf_object__load_skeletonは bpf_object__load→bpf_object_loadを呼びます。
7464 static int bpf_object_load(struct bpf_object *obj, int extra_log_level, const char *target_btf_path) 7465 { ... 7485 err = err ? : bpf_object__create_maps(obj); ... 7487 err = err ? : bpf_object__load_progs(obj, extra_log_level); ... 7530 }
6.6.1 bpf_object__create_maps
bpf_object_loadでは、7485行目でbpfシステムコールを使ってmapを作成しています。
bpf_object__create_maps→bpf_object__create_map→bpf_map_create→sys_bpf_fd→sys_bpf
という流れで処理され、最終的にはbpfシステムコールをcmd=BPF_MAP_CREATEで呼び出すことで、mapを作成しています。
ちなみにrodataセクションに配置されたmapについては、
ここでbpf_object__populate_internal_mapを呼び出し、BPF_MAP_FREEZEでbpfシステムコールを呼び出すことで、read onlyにしています。
6.6.2 bpf_object__load_progs
bpf_object__load_progsでは、tracepoint__syscalls__sys_enter_openなどのBPFプログラムのロジック部分をカーネルにロードします。
bpf_object__load_progs→bpf_object_load_prog→bpf_object_load_prog_instance→bpf_prog_load→sys_bpf_prog_load
の流れで処理され、最終的にはbpfシステムコールをcmd=BPF_PROG_LOADで呼び出すことで、プログラム部分をカーネルにロードしています。
6.7 opensnoop_bpf__attach
opensnoop_bpf__loadでbpfシステムコールを呼び出し、Verifierで検証された後でJITコンパイルが行われネイティブコードになりカーネルのロードが完了します。
イベント発生時にBPFプログラムを動作させるには、ロードしたBPFプログラムをフックポイントにアタッチする必要があります。
これを行うのがopensnoop_bpf__attachです。
opensnoop_bpf__attachのコードは、スケルトンヘッダに存在し、以下のようにlibbpfのbpf_object__attach_skeletonを呼ぶだけです。
110 static inline int 111 opensnoop_bpf__attach(struct opensnoop_bpf *obj) 112 { 113 return bpf_object__attach_skeleton(obj->skeleton); 114 }
bpf_object__attach_skeletonはカーネルにロードした個々のBPFプログラムについて、bpf_program__attachを呼びます。
attach_fnは、ここで宣言されており、BPFプログラムをどこのセクションに配置したかで変わります。
tracepointセクションに配置された場合に呼ばれるattach_tpは、内部で
bpf_program__attach_tracepoint→bpf_program__attach_tracepoint_optsと処理が進められます。
bpf_program__attach_tracepoint_optsがアタッチ処理のメイン部分になっていて、以下のようになっています。
10318 struct bpf_link *bpf_program__attach_tracepoint_opts(const struct bpf_program *prog, 10319 const char *tp_category, 10320 const char *tp_name, 10321 const struct bpf_tracepoint_opts *opts) 10322 { ... 10333 pfd = perf_event_open_tracepoint(tp_category, tp_name); ... 10340 link = bpf_program__attach_perf_event_opts(prog, pfd, &pe_opts); ... 10350 }
perf_event_open_tracepointでperf_event_openシステムコールを呼び出し、PERF_TYPE_TRACEPOINTに対応したファイルディスクリプタを作成します。
perfとは、Linuxにおけるパフォーマンスモニタリングを行うための仕組みです。
CPUのカウンタ値を取得する際などに使用するperfコマンドは、内部でperf_event_openシステムコールを呼び出しているようです。
上記の通り、BPFでtracepointにアタッチする場合だと、perfの仕組みを利用していますが、
例えばBPFプログラム内のSEC()で"kprobe/"のように指定した場合は、kprobeの仕組みを利用します。
libbpf-toolsだと、例えばbindsnoopなどがkprobeの仕組みを使用しています。
bpf_program__attach_perf_event_opts→bpf_link_createと処理が行われ、最終的にはbpfシステムコールをcmd=BPF_LINK_CREATEで呼び出してアタッチしています。 ただし、カーネル側がBPF_LINK_CREATEに対応していない場合は、ioctl(PERF_EVENT_IOC_SET_BPF)でアタッチするようです。 その後、ioctl(PERF_EVENT_IOC_ENABLE)でperfイベントを有効することで、perfイベントが発生したときにBPFプログラムが実行されるようにしています。
6.8 279-308行目
アタッチが完了すれば、あとはBPFプログラムがmapに出力する内容をBPFアプリケーション側で読み取って出力するだけです。
perf_buffer__newとperf_buffer__pollは、まさにそれを行っており、
perf_buffer__newでポーリングするmapとイベントが発生したときに呼び出されるハンドラ（handle_event）をセットし、
終了条件を満たすまでperf_buffer__pollでイベント（mapへの書き込み）を待っています。
画面出力部分は、総じて難しいことは行っていないので割愛します。
また余談ですが、現在ではopensnoopで使用しているperf_bufferを使ったやり方よりも、ringbufを使う方がいいみたいです。本記事はopensnoopの解説がテーマなのでringbufは追及しません。
さて、perf_buffer__newは関数マクロになっており、実際にはperf_buffer__new_v0_6_0が呼ばれ、そこからメイン処理である
__perf_buffer__newが呼ばれます。
__perf_buffer__newでは、cpu*という変数名がありますが、これはperf_bufferがCPUごとに持つバッファのためです。
__perf_buffer__newは以下のようになっています。
10945 static struct perf_buffer *__perf_buffer__new(int map_fd, size_t page_cnt, 10946 struct perf_buffer_params *p) 10947 { ... 10965 err = bpf_obj_get_info_by_fd(map_fd, &map, &map_info_len); ... 10991 pb->sample_cb = p->sample_cb; ... 10999 pb->epoll_fd = epoll_create1(EPOLL_CLOEXEC); ... 11038 for (i = 0, j = 0; i < pb->cpu_cnt; i++) { ... 11050 11051 cpu_buf = perf_buffer__open_cpu_buf(pb, p->attr, cpu, map_key); ... 11059 err = bpf_map_update_elem(pb->map_fd, &map_key, 11060 &cpu_buf->fd, 0); ... 11068 11069 pb->events[j].events = EPOLLIN; 11070 pb->events[j].data.ptr = cpu_buf; 11071 if (epoll_ctl(pb->epoll_fd, EPOLL_CTL_ADD, cpu_buf->fd, 11072 &pb->events[j]) < 0) { ... 11078 } ... 11080 } ... 11091 }
10965行目でカーネル内に作成したmapのファイルディスクリプタを取得しています。
このmapはBPFプログラムでeventsとして宣言していたものです。
その後、pb（perf_buffer構造体）をアロケートし、10991行目でp->sample_cbを代入していますが、
このsample_cbがopensnoop.cから渡されるhandle_eventになります。
10999行目でepollのファイルディスクリプタを作成していますが、このファイルディスクリプタが後でperf_buffer__pollするときにイベント待ちに使われるものです。
11051行目でperf_buffer__open_cpu_bufを呼び、CPU数分バッファの作成とperf_event_openシステムコールの呼び出しなどを行っています。
perf_buffer__open_cpu_bufでやっていることは、BPFプログラム側で呼んでいるbpf_perf_event_outputを使うために必要なことのようです。
bpf_perf_event_outputのマニュアルにユーザ空間で読みだすためにはどのような手続きが必要かの記載があります。
11059行目でeventsとCPUごとのバッファを紐づけています。keyは、ループのインデックス（i）です。
11071行目でepoll_ctlを呼び、CPUごとのバッファをepollの監視対象にします。
次にperf_buffer__pollですが、以下のようなコードになっています。
11106 static enum bpf_perf_event_ret 11107 perf_buffer__process_record(struct perf_event_header *e, void *ctx) 11108 { 11109 struct perf_cpu_buf *cpu_buf = ctx; 11110 struct perf_buffer *pb = cpu_buf->pb; 11111 void *data = e; ... 11117 switch (e->type) { 11118 case PERF_RECORD_SAMPLE: { 11119 struct perf_sample_raw *s = data; 11120 11121 if (pb->sample_cb) 11122 pb->sample_cb(pb->ctx, cpu_buf->cpu, s->data, s->size); 11123 break; 11124 } ... 11135 } 11136 return LIBBPF_PERF_EVENT_CONT; 11137 } ... 11139 static int perf_buffer__process_records(struct perf_buffer *pb, 11140 struct perf_cpu_buf *cpu_buf) 11141 { ... 11144 ret = perf_event_read_simple(cpu_buf->base, pb->mmap_size, 11145 pb->page_size, &cpu_buf->buf, 11146 &cpu_buf->buf_size, 11147 perf_buffer__process_record, cpu_buf); ... 11151 } ... 11158 int perf_buffer__poll(struct perf_buffer *pb, int timeout_ms) 11159 { ... 11162 cnt = epoll_wait(pb->epoll_fd, pb->events, pb->cpu_cnt, timeout_ms); ... 11165 11166 for (i = 0; i < cnt; i++) { 11167 struct perf_cpu_buf *cpu_buf = pb->events[i].data.ptr; 11168 11169 err = perf_buffer__process_records(pb, cpu_buf); ... 11174 } ... 11176 }
11162行目でepoll_waitでCPUごとのバッファが読み出し可能になるかタイムアウト（100ミリ秒）になるまでブロックします。
バッファに書き込みが発生したら、11167行目でバッファへのポインタを取り出してperf_buffer__process_recordsを呼び出します。
__perf_buffer__newで作成したバッファは、リングバッファとして使用されており、perf_event_read_simpleでは、実際にバッファに書き込まれたデータを取り出し、
perf_buffer__process_recordに渡します。
最終的には、こちらで呼ばれるsample_cbの呼び出しが、opensnoop.cで渡したhandle_eventになっており、BPFプログラムから渡されたデータの出力が行われます。
7. おわりに
BPFは、ツールも含めまだまだ絶賛開発中の技術です。
昨年は、WindowsでBPFをサポートすることをマイクロソフトが発表するなどLinux以外のOSでもBPFの仕組みは広がりつつあります。
ちなみにBPFがどのような方向に進んでいっているのかは、
Linux Kernel Developers' bpfconf 2022の資料が参考になるかもしれません。
8. 参考文献
Liz Rice. What is eBPF? . O'Reilly Media, Inc, April 2022,
*1:2022年8月11日にv0.25.0がリリースされましたが、本記事では執筆時点で最新だったv0.24.0を対象にしています
