gobee

BPFプログラムをCではなくGoで書きましょう。 gobeeはGoの厳密なサブセットをBPF Cへトランスパイルし、ユーザー空間側の型付きGoバインディングを生成し、実行中のカーネルに応じてロードを制限します。

GoエコシステムにはBPF向けの堅牢なユーザー空間ツールがあります。しかしカーネル側は常に「あとはプログラムをCで書いてください」で終わっていました。Ayaはrustcに新しいBPFバックエンドを実装することでeBPFをRustにもたらしました。gobeeは別の方法、すなわちCへトランスパイルし、clangの成熟したバックエンドを再利用することでそこに到達します。

Goファイルを入れれば、BPFプログラムが出てくる

ringbuf経由ですべてのexecveをユーザー空間にストリーミングするtracepoint:

あなたの入力 (Go)

gobeeが生成するもの (BPF C)

//go:build ignore

package main

import "github.com/boratanrikulu/gobee/bpf"

//bpf:license GPL

type Event struct {
    Pid  uint32
    Comm [16]byte
}

var Events = bpf.RingBuf[Event]{
    MaxEntries: 4096,
}

//bpf:section tracepoint/syscalls/sys_enter_execve
func OnExec(ctx *bpf.ExecveEnterCtx) bpf.TpReturn {
    e, ok := Events.Reserve()
    if !ok {
        return bpf.TpOk
    }
    e.Pid = bpf.GetCurrentPid()
    bpf.GetTaskComm(&e.Comm)
    Events.Submit(e)
    return bpf.TpOk
}

func main() {}

// Code generated by gobee. DO NOT EDIT.

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

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

struct Event {
    __u32 Pid;
    __u8 Comm[16];
};

struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 4096);
} Events SEC(".maps");

SEC("tracepoint/syscalls/sys_enter_execve")
int OnExec(struct trace_event_raw_sys_enter *ctx) {
    struct Event *e = bpf_ringbuf_reserve(
        &Events, sizeof(struct Event), 0);
    if (!e) {
        return 0;
    }
    e->Pid = (__u32)(
        bpf_get_current_pid_tgid() >> 32);
    bpf_get_current_comm(&e->Comm, 16);
    bpf_ringbuf_submit(e, 0);
    return 0;
}

対象

対応状況

プログラムタイプ (8)

XDP、tracepoint、kprobe / kretprobe、uprobe / uretprobe、sock_ops、TC、cgroup_skb、LSM

マップタイプ (19)

array、hash、lru_hash、per-CPUバリアント、bloom_filter、lpm_trie、ringbuf、perf_event_array、prog_array、queue、stack、sk/task/inode ストレージ、devmap/cpumap/xskmap

BPFヘルパー

libbpf v1.5.0ヘッダーから自動生成された約200の型付きGoスタブ。example/helloworld/とexample/sysmon/で使用されているものは実カーネルCIでテスト済みですが、残りは未検証です。スタブがカーネルのシグネチャと一致しない場合はissueを報告してください

CO-RE

✅ 自動検出。カーネル内部の構造体フィールドにはBPF_CORE_READ（task_struct、sock、inode）。UAPI BPFコンテキスト構造体（xdp_md、__sk_buff、bpf_sock_ops）には直接ctx->field。Linux 6.x（Ubuntu 24.04 CI）で検証済み。より古いカーネルはまだCIマトリクスに含まれていません

BTF対応出力

✅ 生成されるCはvmlinux.hを含み、カーネル内部フィールドの読み取りにBPF_CORE_READを使用するため、clang -gからclangが生成するBTFには正しいリロケーションが含まれます。clang自体の実行はあなたの責任です（サンプルのMakefileに標準的な呼び出し方が示されています）

ユーザー定義ヘルパー

✅ //bpf:sectionを持たないトップレベルGo関数は、static __always_inline C関数として出力されます

型付きGoバインディング

✅ Load<Stem>、Close、プログラムごとのAttach<Name>、AttachAllに加え、カーネル側の構造体型と定数がGoで再公開されます

カーネルバージョンゲート

✅ ロード時にbpfvetが実行されます。不透明なEINVALの代わりに、bpf program needs kernel >= 5.8, host is 5.4というメッセージで即座に失敗します

Verifierエラー → Goソース

✅ Load<Stem>内で自動的に注釈付けされます。gobee diagnoseへの手動パイプは不要で、にマーカーが付いて返ってきます

	gobee	C + clang + bpf2go	Aya (Rust)	bpftrace	BCC
カーネル側言語	Goサブセット	C	Rust	DSL	C
ユーザー空間統合	型付きGoバインディング + cilium/ebpf	bpf2go	aya-runtime	なし	python
CO-RE	✅ clang経由	✅	✅ LLVM経由	✅	✅
ヘルパー網羅性	200の型付きGoラッパー	フル（Cで記述）	フル	限定	フル（Cで記述）
Verifierエラー → ソース	✅ Go file:line:col	❌ 生のC	✅ Rust file:line	❌	部分的
ロード時のカーネルバージョンゲート	✅ bpfvet経由	手動	手動	該当なし	ランタイム
ツールチェーン依存	Go + clang	clang + bpf2go	rustc + LLVM	bpftrace	python + bcc
生成成果物	`.bpf.o` + Goバイナリ	`.bpf.o` + Goバイナリ	`.bpf.o` + Rustバイナリ	JIT	JIT

gobee

人気

比較

現在サポートされているもの

gobeeが行うこと

gobeeがやらないこと

なぜ直接BPFを生成せずトランスパイルするのか

クイックスタート

プロジェクト構成（典型的な構成）

例

CI

ドキュメント

ツールチェーン

インスピレーション

ライセンス