gobee

Scrivi i tuoi programmi BPF in Go, non in C. gobee transpila un sottoinsieme rigoroso di Go in BPF C, genera binding Go tipizzati per il lato userspace e controlla i load rispetto al kernel in esecuzione.

L'ecosistema Go ha strumenti userspace solidi per BPF. Il lato kernel si è sempre concluso con "ora scrivi il tuo programma in C." Aya ha portato eBPF su Rust scrivendo un nuovo backend BPF in rustc. gobee ci arriva in un altro modo: transpilando in C e riusando il backend maturo di clang.

Un file Go in ingresso, un programma BPF in uscita

Un tracepoint che invia in streaming ogni execve allo userspace tramite un ringbuf:

//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;
}

gobee translate --bindings-dir ./bpf ./bpf/src produce entrambi i file, più una sourcemap (events.bpf.c.map) così gli errori del verifier vengono mappati sulle righe Go e un file di binding tipizzati (bpf/events_bindings.go) così il driver userspace scrive objs.Events, objs.AttachOnExec() e decodifica i payload del ringbuf direttamente in bpf.Event (la stessa struct che vedi sopra, ripubblicata in Go) invece di lookup coll.Programs["..."] tipizzati come stringhe.

Il C è leggibile di proposito. Se gobee emette qualcosa di strano, puoi vederlo. Per tracepoint + kprobe + XDP combinati in un unico binario, vedi example/sysmon/.

Come si confronta

Se sei già in un workflow C / libbpf, gobee non cerca di sostituirlo del tutto. È pensato per i casi in cui vuoi il lato kernel, il lato userspace e la pipeline di build tutti in un unico modulo Go.

Cosa è supportato oggi

Vedi docs/status.md per la matrice completa (sottoinsieme di Go, statement, espressioni, ogni helper, ogni tipo di mappa, ogni direttiva). Vista rapida:

Cosa fa gobee

• Transpila un sottoinsieme di Go in BPF C (ed esegue go/types sul tuo input prima, così gli usi errati emergono a file:line:col).
• Genera un <Stem>_bindings.go tipizzato accanto al .bpf.c: bpf.LoadCounter(spec), objs.PerIface.Lookup(...), objs.AttachAll(ifindex), più i tuoi tipi di struct lato kernel e le costanti ripubblicati in Go.
• Annota automaticamente *ebpf.VerifierError di LoadAndAssign con posizioni nel sorgente Go, senza bisogno di pipe manuale verso gobee diagnose.
• Esegue bpfvet all'interno di Load<Stem> così i kernel vecchi falliscono rapidamente con bpf program needs kernel >= 5.8, host is 5.4.
• Espone circa 200 stub Go tipizzati per il set di helper libbpf v1.5.0, più funzioni helper definite dall'utente emesse come static __always_inline.

Cosa gobee non farà

• Sostituire clang. Il backend BPF di clang ci dà gratuitamente CO-RE, BTF e codegen amico del verifier. Reimplementarlo costa anni e non porta alcun vantaggio.
• Sostituire cilium/ebpf. I binding generati si appoggiano su di esso.
• Nascondere BPF. Il sottoinsieme di Go mappa 1:1 agli idiomi di BPF C. Se conosci BPF, gobee è zucchero sottile. Se non lo conosci, il manuale resta comunque lettura obbligatoria.
• Eseguire clang al posto tuo. Compilazione, embedding e load restano a carico dell'utente. Stesso schema di bpf2go.

Perché transpilare, invece di generare BPF direttamente

gc, il compilatore Go, non ha un backend BPF basato su LLVM. Aggiungerne uno è un progetto di compilatore pluriennale. rustc è costruito su LLVM ed è per questo che Aya funziona. Quindi gobee emette C e riusa il backend BPF di clang, che ci dà gratuitamente codegen maturo, BTF e rilocazioni CO-RE.