在 Introduction to eBPF 这篇文章中介绍了基于内核源码开发并加载 eBPF 代码的过程。本文将介绍基于 Go 和对应的库开发 eBPF 程序，文中所有涉及的代码可以在我的 Github 中找到。

选择 eBPF 库

当涉及到选择库和工具来与 eBPF 进行交互时，会让人有所困惑。在选择时，你必须在基于 Python 的 BCC 框架、基于 C 的 libbpf 和一系列基于 Go 的 Dropbox、Cilium、Aqua 和 Calico 等库中选择。

在大多数情况下，eBPF 库主要协助实现两个功能：

• 将 eBPF 程序和 Map 载入内核并执行重定位，通过其文件描述符将 eBPF 程序与正确的 Map 进行关联。
• 与 eBPF Map 交互，允许对存储在 Map 中的键/值对进行标准的 CRUD 操作。

部分库也可以帮助你将 eBPF 程序附加到一个特定的钩子，尽管对于网络场景下，这可能很容易采用现有的 netlink API 库完成。

当涉及到 eBPF 库的选择时，仍然让人感到困惑（见[1], [2]）。事实是每个库都有各自的范围和限制。

• Calico 在用 bpftool 和 iproute2 实现的 CLI 命令基础上实现了一个 Go 包装器。
• Aqua 实现了对 libbpf C 库的 Go 包装器。
• Dropbox 支持一小部分程序，但有一个非常干净和方便的用户API。
• IO Visor 的 gobpf 是 BCC 框架的 Go 语言绑定，它更注重于跟踪和性能分析。
• Cilium 和 Cloudflare 维护一个 纯 Go 语言编写的库 (以下简称 “libbpf-go”)，它将所有 eBPF 系统调用抽象在一个本地 Go 接口后面。

参考 使用 Go 语言管理和分发 ebpf 程序 可以看到 cilium/ebpf 更加活跃，本文也选择基于 cilium/ebpf 库来开发。cilium/ebpf 纯 Go 程序编写，从而实现了程序最小依赖；与此同时其还提供了 bpf2go 工具，可用来将 eBPF 程序编译成 Go 语言中的一部分，使得交付更加方便，后续如果配合 CO-RE 功能则威力大增。

环境准备

eBPF 程序一般有两部分组成：

1. 基于 C 语言的 eBPF 程序，最终使用 clang/llvm 编译成 elf 格式的文件，为内核中需要加载的程序；
2. Go 语言程序用于加载、调试 eBPF 程序，为用户空间的程序，用于配置或者读取 eBPF 程序生成的数据。

前置条件需要安装 clang/llvm 编译器：

1
2
3
4

# 安装 llvm 编译器，至少要求 clang 9.0 版本以上
$ sudo apt update -y
$ sudo apt install -y llvm
$ sudo apt install -y clang

可以从我的 Github 下载代码，目录结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[root@VM-4-27-centos demo]# tree
.
|-- bpf
|   |-- headers
|   |   |-- bpf_core_read.h
|   |   |-- bpf_helper_defs.h
|   |   |-- bpf_helpers.h
|   |   |-- bpf_tracing.h
|   |   |-- update.sh
|   |   `-- vmlinux.h
|   `-- kprobe.c
|-- Dockerfile
|-- go.mod
|-- go.sum
|-- main.go
`-- Makefile

编程规范

BPF 代码

以 kprobe 为例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// +build ignore

#include "vmlinux.h"
#include "bpf_helpers.h"

char __license[] SEC("license") = "Dual MIT/GPL";

struct bpf_map_def SEC("maps") kprobe_map = {
    .type = BPF_MAP_TYPE_ARRAY,
    .key_size = sizeof(u32),
    .value_size = sizeof(u64),
    .max_entries = 1,
};

SEC("kprobe/sys_execve")
int kprobe_execve() {
    u32 key = 0;
    u64 initval = 1, *valp;

    valp = bpf_map_lookup_elem(&kprobe_map, &key);
    if (!valp) {
        bpf_map_update_elem(&kprobe_map, &key, &initval, BPF_ANY);
        return 0;
    }
    __sync_fetch_and_add(valp, 1);

    return 0;
}

头文件

libbpf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

#!/usr/bin/env bash

# Version of libbpf to fetch headers from
LIBBPF_VERSION=0.5.0

# The headers we want
prefix=libbpf-"$LIBBPF_VERSION"
headers=(
    "$prefix"/src/bpf_core_read.h
    "$prefix"/src/bpf_helper_defs.h
    "$prefix"/src/bpf_helpers.h
    "$prefix"/src/bpf_tracing.h
)

# Fetch libbpf release and extract the desired headers
curl -sL "https://github.com/libbpf/libbpf/archive/refs/tags/v${LIBBPF_VERSION}.tar.gz" | \
    tar -xz --xform='s#.*/##' "${headers[@]}"

vmlinux.h

vmlinux.h 是使用工具生成的代码文件。它包含了系统运行 Linux 内核源代码中使用的所有类型定义。当我们编译 Linux 内核时，会输出一个称作 vmlinux 的文件组件，其是一个 ELF 的二进制文件，包含了编译好的可启动内核。vmlinux 文件通常也会被打包在主要的 Linux 发行版中。

内核中的 bpftool 工具其中功能之一就是读取 vmlinux 文件并生成对应的 vmlinux.h 头文件。vmlinux.h 会包含运行内核中所使用的每一个类型定义，因此该文件的比较大。

生成 vmlinux.h 文件的命令如下：

1

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

包含该 vmlinux.h，就意味着我们的程序可以使用内核中使用的所有数据类型定义，因此 BPF 程序在读取相关的内存时，就可以映射成对应的类型结构按照字段进行读取。

例如，Linux 中的 task_struct 结构用于表示进程，如果 BPF 程序需要检查 task_struct 结构的值，那么首先就需要知道该结构的具体类型定义。

由于 vmlinux.h 文件是由当前运行内核生成的，如果你试图将编译好的 eBPF 程序在另一台运行不同内核版本的机器上运行，可能会面临崩溃的窘境。这主要是因为在不同的版本中，对应数据类型的定义可能会在 Linux 源代码中发生变化。

但是，通过使用 libbpf 库提供的功能可以实现 “CO:RE”（一次编译，到处运行）。libbpf 库定义了部分宏（比如 BPF_CORE_READ），其可分析 eBPF 程序试图访问 vmlinux.h 中定义的类型中的哪些字段。如果访问的字段在当前内核定义的结构中发生了移动，宏 / 辅助函数会协助自动找到对应字段。对于可能消失的字段，也提供了对应的辅助函数 bpf_core_field_exists。因此，我们可以使用当前内核中生成的 vmlinux.h 头文件来编译 eBPF 程序，然后在不同的内核上运行它【需要运行的内核也支持 BTF 内核编译选项】。

代码编译

bpf2go

该注解使用 bpf2go 程序将 kprobe.c 文件编译成 bpfdemo_bpfeb.go 和 bpfdemo_bpfel.go 两个文件，分别为 bigendian 和 littleendian 两种平台的程序。

其中参数中的 BPFDemo 参数为 main.go 文件中函数调用的名称，例如 objs := BPFDemoObjects{} 和 LoadBPFDemoObjects(&objs, nil);

1
2
3
4
5
6
7

// SPDX-License-Identifier: GPL-2.0-only
// Copyright (C) 2021 Authors of Nylon */

//go:generate sh -c "echo Generating for amd64"
//go:generate go run github.com/cilium/ebpf/cmd/bpf2go -cc clang BPFDemo ./bpf/kprobe.c -- -DOUTPUT_SKB -D__TARGET_ARCH_x86 -I./bpf/headers

package main

Makefile

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

GO := go
GO_BUILD = CGO_ENABLED=0 $(GO) build
GO_GENERATE = $(GO) generate
GO_TAGS ?=
TARGET=BPFDemo
BINDIR ?= /usr/local/bin
VERSION=$(shell git describe --tags --always)

$(TARGET):
$(GO_GENERATE)
$(GO_BUILD) $(if $(GO_TAGS),-tags $(GO_TAGS)) \
-ldflags "-w -s \
-X 'github.com/SimpCosm/godemo/ebpf/BPFDemo.Version=${VERSION}'"

clean:
rm -f $(TARGET)
rm -f bpfdemo_bpf*
rm -rf ./release

执行编译，可以看到生成了对应的 BPF 字节码 bpfdemo_bpfeb.o 和 bpfdemo_bpfel.o，还有对应的 go 文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

[root@VM-4-27-centos demo]# make
go generate
Generating for amd64
Compiled /root/demo/bpfdemo_bpfel.o
Stripped /root/demo/bpfdemo_bpfel.o
Wrote /root/demo/bpfdemo_bpfel.go
Compiled /root/demo/bpfdemo_bpfeb.o
Stripped /root/demo/bpfdemo_bpfeb.o
Wrote /root/demo/bpfdemo_bpfeb.go
CGO_ENABLED=0 go build  \
-ldflags "-w -s \
-X 'github.com/SimpCosm/godemo/ebpf/BPFDemo.Version='"
[root@VM-4-27-centos demo]# ls
Dockerfile  bpf               bpfdemo_bpfeb.o   bpfdemo_bpfel.o  go.mod  main.go        main_arm64.go
Makefile    bpfdemo_bpfeb.go  bpfdemo_bpfel.go  demo             go.sum  main_amd64.go

加载代码

在我们编写的 Go 代码中，首先需要将编译好的 eBPF 代码加载进内核，调用的是 LoadBPFDemoObjects

1
2
3
4
5
6

// Load pre-compiled programs and maps into the kernel.
objs := BPFDemoObjects{}
if err := LoadBPFDemoObjects(&objs, nil); err != nil {
log.Fatalf("loading objects: %v", err)
}
defer objs.Close()

这里的 LoadBPFDemoObjects 和 BPFDemoObjects 都来自 bpf2go 自动生成的代码。

以 bpfdemo_bpfeb.go 为例，可以看到生成了很多辅助函数和结构体，其中：

• BPFDemoObjects 包括 BPF 程序和 BPF Map
• LoadBPFDemoObjects 会调用 LoadBPFDemo 将编译好的 ELF 格式的 BPF 代码加载进内存，然后调用 LoadAndAssign 实际调用 BPF 系统调用 load BPF 程序到内核。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

// BPFDemoMaps contains all maps after they have been loaded into the kernel.
//
// It can be passed to LoadBPFDemoObjects or ebpf.CollectionSpec.LoadAndAssign.
type BPFDemoMaps struct {
        KprobeMap *ebpf.Map `ebpf:"kprobe_map"`
}

// BPFDemoPrograms contains all programs after they have been loaded into the kernel.
//
// It can be passed to LoadBPFDemoObjects or ebpf.CollectionSpec.LoadAndAssign.
type BPFDemoPrograms struct {
        KprobeExecve *ebpf.Program `ebpf:"kprobe_execve"`
}

// BPFDemoObjects contains all objects after they have been loaded into the kernel.
//
// It can be passed to LoadBPFDemoObjects or ebpf.CollectionSpec.LoadAndAssign.
type BPFDemoObjects struct {
        BPFDemoPrograms
        BPFDemoMaps
}

// LoadBPFDemoObjects loads BPFDemo and converts it into a struct.
//
// The following types are suitable as obj argument:
//
//     *BPFDemoObjects
//     *BPFDemoPrograms
//     *BPFDemoMaps
//
// See ebpf.CollectionSpec.LoadAndAssign documentation for details.
func LoadBPFDemoObjects(obj interface{}, opts *ebpf.CollectionOptions) error {
        spec, err := LoadBPFDemo()
        if err != nil {
                return err
        }

        return spec.LoadAndAssign(obj, opts)
}

实际查看 LoadAndAssign 可以看到它会加载 BPF Program 和 BPF Map 到内核

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// LoadAndAssign loads Maps and Programs into the kernel and assigns them
// to a struct.
//    struct {
//        Foo     *ebpf.Program `ebpf:"xdp_foo"`
//        Bar     *ebpf.Map     `ebpf:"bar_map"`
//        Ignored int
//    }
func (cs *CollectionSpec) LoadAndAssign(to interface{}, opts *CollectionOptions) error {
loader := newCollectionLoader(cs, opts)
defer loader.cleanup()

// Support assigning Programs and Maps, lazy-loading the required objects.
assignedMaps := make(map[string]bool)
getValue := func(typ reflect.Type, name string) (interface{}, error) {
switch typ {

case reflect.TypeOf((*Program)(nil)):
return loader.loadProgram(name)

case reflect.TypeOf((*Map)(nil)):
assignedMaps[name] = true
return loader.loadMap(name)

default:
return nil, fmt.Errorf("unsupported type %s", typ)
}
}
  //...
}

这里的 loadProgram 会调用 newProgramWithOptions，处理很多与 BTF 等其他内容后，最终调用 sys.ProgLoad(attr)

1
2
3
4
5
6

func newProgramWithOptions(spec *ProgramSpec, opts ProgramOptions, handles *handleCache) (*Program, error) {
    // ...
    fd, err := sys.ProgLoad(attr)
  
    // ...
}

此即调用了 BPF 的系统调用：

1
2
3
4
5
6
7

func ProgLoad(attr *ProgLoadAttr) (*FD, error) {
fd, err := BPF(BPF_PROG_LOAD, unsafe.Pointer(attr), unsafe.Sizeof(*attr))
if err != nil {
return nil, err
}
return NewFD(int(fd))
}

加载 map 也是类似，最终调用了 sys.MapCreate

1
2
3
4
5
6
7

func MapCreate(attr *MapCreateAttr) (*FD, error) {
fd, err := BPF(BPF_MAP_CREATE, unsafe.Pointer(attr), unsafe.Sizeof(*attr))
if err != nil {
return nil, err
}
return NewFD(int(fd))
}

Kprobe 处理

kprobe可以对任何内核函数进行插桩，可以实时在生产环境中启用，不需要重启系统，也不需要以特殊方式重启内核。
现在有以下三种接口可以访问kprobes.

• kprobe API: 如 register_kprobe() 等，在 这篇文章中 介绍了其用法
• 基于Frace的，通过 /sys/kernel/debug/tracing/kprobe_events: 通过向这个文件写入字符串，可以配置开启和停止kprobes，在 这篇文章中 介绍了其用法
• perf_event_open(): 与 perf 工具所使用的一样，现在BPF跟踪工具也开始使用这些函数

对应到 main.go 中，在 LoadBPFDemoObjects之后，我们还调用了 link.Kprobe 来

1
2
3
4
5
6
7
8
9

// Open a Kprobe at the entry point of the kernel function and attach the
// pre-compiled program. Each time the kernel function enters, the program
// will increment the execution counter by 1. The read loop below polls this
// map value once per second.
kp, err := link.Kprobe(fn, objs.KprobeExecve)
if err != nil {
log.Fatalf("opening kprobe: %s", err)
}
defer kp.Close()

创建 kprobe类型的 perf event

• symbol 是追踪的内核函数
• prog 是编译的 eBPF 程序

1
2
3
4
5
6
7
8
9
10
11
12
13
14

func Kprobe(symbol string, prog *ebpf.Program, opts *KprobeOptions) (Link, error) {
   k, err := kprobe(symbol, prog, opts, false)
   if err != nil {
      return nil, err
   }

   lnk, err := attachPerfEvent(k, prog)
   if err != nil {
      k.Close()
      return nil, err
   }

   return lnk, nil
}

这里创建了一个 kprobe 类型的 Perf Event，传入的追踪地址是 symbol

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

// kprobe opens a perf event on the given symbol and attaches prog to it.
// If ret is true, create a kretprobe.
func kprobe(symbol string, prog *ebpf.Program, opts *KprobeOptions, ret bool) (*perfEvent, error) {
  // ...
  
args := probeArgs{
pid:    perfAllThreads,
symbol: platformPrefix(symbol),
ret:    ret,
}

// Use kprobe PMU if the kernel has it available.
tp, err := pmuKprobe(args)
if err == nil {
return tp, nil
}
  
  // ... 
  
// Use tracefs if kprobe PMU is missing.
args.symbol = platformPrefix(symbol)
tp, err = tracefsKprobe(args)
  // ...

return tp, nil
}

最终调用了 PerfEventOpen 来开启一个 perf event，这个系统调用可以参考 这里

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// pmuProbe opens a perf event based on a Performance Monitoring Unit.
//
// Requires at least a 4.17 kernel.
// e12f03d7031a "perf/core: Implement the 'perf_kprobe' PMU"
// 33ea4b24277b "perf/core: Implement the 'perf_uprobe' PMU"
//
// Returns ErrNotSupported if the kernel doesn't support perf_[k,u]probe PMU
func pmuProbe(typ probeType, args probeArgs) (*perfEvent, error) {
  // ...
switch typ {
case kprobeType:
// Create a pointer to a NUL-terminated string for the kernel.
sp, err = unsafeStringPtr(args.symbol)

attr = unix.PerfEventAttr{
Type:   uint32(et),          // PMU event type read from sysfs
Ext1:   uint64(uintptr(sp)), // Kernel symbol to trace
Config: config,              // Retprobe flag
}
case uprobeType:
    // ...
}

rawFd, err := unix.PerfEventOpen(&attr, args.pid, 0, -1, unix.PERF_FLAG_FD_CLOEXEC)
fd, err := sys.NewFD(rawFd)
  
  // ...
// Kernel has perf_[k,u]probe PMU available, initialize perf event.
return &perfEvent{
typ:    typ.PerfEventType(args.ret),
name:   args.symbol,
pmuID:  et,
cookie: args.cookie,
fd:     fd,
}, nil
}

挂载 eBPF 程序到 perf event

通过 perf_event 的 ioctl 调用把 BPF 程序 attach 到 kprobe event

• PERF_EVENT_IOC_SET_BPF，表示允许 attach BPF 程序到 kprobe event 上，其中 ioctl 设置的第三个参数代表 bpf 系统调用的 fd。
• PERF_EVENT_IOC_ENABLE，表示使能 event。

1
2

ioctl(perf_event_fd, PERF_EVENT_IOC_SET_BPF, bpf_prog_fd)
ioctl(perf_event_fd, PERF_EVENT_IOC_ENABLE, 0)

attachPerfEvent 通过 perf_event 的 ioctl 调用把 BPF 程序 attach 到 kprobe event

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

// attach the given eBPF prog to the perf event stored in pe.
// pe must contain a valid perf event fd.
// prog's type must match the program type stored in pe.
func attachPerfEvent(pe *perfEvent, prog *ebpf.Program) (Link, error) {
if prog == nil {
return nil, errors.New("cannot attach a nil program")
}
if prog.FD() < 0 {
return nil, fmt.Errorf("invalid program: %w", sys.ErrClosedFd)
}

switch pe.typ {
case kprobeEvent, kretprobeEvent, uprobeEvent, uretprobeEvent:
if t := prog.Type(); t != ebpf.Kprobe {
return nil, fmt.Errorf("invalid program type (expected %s): %s", ebpf.Kprobe, t)
}
case tracepointEvent:
if t := prog.Type(); t != ebpf.TracePoint {
return nil, fmt.Errorf("invalid program type (expected %s): %s", ebpf.TracePoint, t)
}
default:
return nil, fmt.Errorf("unknown perf event type: %d", pe.typ)
}

if err := haveBPFLinkPerfEvent(); err == nil {
lnk, err := attachPerfEventLink(pe, prog)
if err != nil {
return nil, err
}
return lnk, nil
}

lnk, err := attachPerfEventIoctl(pe, prog)
if err != nil {
return nil, err
}

return lnk, nil
}

通过 ioctl 挂载 BPF 程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

func attachPerfEventIoctl(pe *perfEvent, prog *ebpf.Program) (*perfEventIoctl, error) {
if pe.cookie != 0 {
return nil, fmt.Errorf("cookies are not supported: %w", ErrNotSupported)
}

// Assign the eBPF program to the perf event.
err := unix.IoctlSetInt(pe.fd.Int(), unix.PERF_EVENT_IOC_SET_BPF, prog.FD())
if err != nil {
return nil, fmt.Errorf("setting perf event bpf program: %w", err)
}

// PERF_EVENT_IOC_ENABLE and _DISABLE ignore their given values.
if err := unix.IoctlSetInt(pe.fd.Int(), unix.PERF_EVENT_IOC_ENABLE, 0); err != nil {
return nil, fmt.Errorf("enable perf event: %s", err)
}

pi := &perfEventIoctl{pe}

// Close the perf event when its reference is lost to avoid leaking system resources.
runtime.SetFinalizer(pi, (*perfEventIoctl).Close)
return pi, nil
}

查看 Map 信息

定期查看 eBPF map 的更新：

1
2
3
4
5
6
7
8
9
10
11
12
13

// Read loop reporting the total amount of times the kernel
// function was entered, once per second.
ticker := time.NewTicker(1 * time.Second)

log.Println("Waiting for events..")

for range ticker.C {
var value uint64
if err := objs.KprobeMap.Lookup(mapKey, &value); err != nil {
log.Fatalf("reading map: %v", err)
}
log.Printf("%s called %d times\n", fn, value)
}

容器镜像

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

FROM ubuntu:20.04
RUN apt update -y -q
RUN DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends -y -q curl build-essential ca-certificates
RUN curl -s https://storage.googleapis.com/golang/go1.16.3.linux-amd64.tar.gz| tar -v -C /usr/local -xz
ENV PATH $PATH:/usr/local/go/bin
RUN apt install -y wget gnupg2
RUN printf "deb http://apt.llvm.org/xenial/ llvm-toolchain-xenial-12 main" | tee /etc/apt/sources.list.d/llvm-toolchain-xenial-12.list
RUN wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add -
RUN apt -y update
RUN apt install -y llvm clang git
WORKDIR /ebpf
COPY . .
RUN make
RUN chmod a+x /ebpf
ENTRYPOINT ["./ebpf"]
CMD ["./ebpf"]

参考资料

• https://networkop.co.uk/post/2021-03-ebpf-intro/
• https://www.grant.pizza/blog/vmlinux-header/
• https://www.ebpf.top/post/ebpf_go_translation/
• https://tinylab.org/bcc-overview/
• https://www.brendangregg.com/blog/2021-06-15/bpf-internals.html

eBPF Map 是用户空间和内核空间进行数据交换、信息传递的桥梁，它以 key/value 方式将数据存储在内核中，可以被任何知道它们的BPF程序访问。在内核空间的程序创建 BPF Map 并返回对应的 文件描述符，在用户空间运行的程序就可以通过这个文件描述符来访问并操作BPF Map。eBPF Map 支持多种数据结构类型，在 上一篇博客 中已经简单介绍过，本文将通过代码实例展示其使用方法，所有代码可以在我的 Github 中找到。

创建BPF Map

最初创建 BPF Map 的方式都是通过 bpf 系统调用函数，传入的第一个参数是BPF_MAP_CREATE，在 上一篇博客 中已经介绍，此处不在详述。

1
2
3
4
5
6
7
8
9

union bpf_attr my_map_attr {
  .map_type = BPF_MAP_TYPE_ARRAY,
  .key_size = sizeof(int),
  .value_size = sizeof(int),
  .max_entries = 1024,
  .map_flags = BPF_F_NO_PREALLOC,
};

int fd = bpf(BPF_MAP_CREATE, &my_map_attr, sizeof(my_map_attr));

相对于直接使用 bpf 系统调用函数来创建BPF Map，在实际场景中常用的是基于 SEC("maps") 这个语法糖来做到声明即创建：

1
2
3
4
5
6
7

struct bpf_map_def SEC("maps") my_bpf_map = {
  .type       = BPF_MAP_TYPE_HASH, 
  .key_size   = sizeof(int),
  .value_size   = sizeof(int),
  .max_entries = 100,
  .map_flags   = BPF_F_NO_PREALLOC,
};

关键点就是SEC("maps")，ELF convention，它的工作原理是这样的：

• 声明 ELF Section 属性 SEC("maps")
• 内核代码bpf_load.c 扫描目标文件中所有 Section 信息，它会扫描目标文件里定义的 Section，其中就有用来创建BPF Map的SEC("maps")，我们可以到相关代码里看到说明：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// https://elixir.bootlin.com/linux/v4.15/source/samples/bpf/bpf_load.h#L41
/* parses elf file compiled by llvm .c->.o
 * . parses 'maps' section and creates maps via BPF syscall // 就是这里
 * . parses 'license' section and passes it to syscall
 * . parses elf relocations for BPF maps and adjusts BPF_LD_IMM64 insns by
 *   storing map_fd into insn->imm and marking such insns as BPF_PSEUDO_MAP_FD
 * . loads eBPF programs via BPF syscall
 *
 * One ELF file can contain multiple BPF programs which will be loaded
 * and their FDs stored stored in prog_fd array
 *
 * returns zero on success
 */
int load_bpf_file(char *path);

• bpf_load.c扫描到SEC("maps")后，对BPF Map相关的操作是由load_maps函数完成，其中的bpf_create_map_node()和bpf_create_map_in_map_node()就是创建BPF Map的关键函数
• 它们背后都是调用了定义在内核代码tools/lib/bpf/bpf.c中的方法，而这个方法就是使用上文提到的BPF_MAP_CREATE命令进行的系统调用。
• 最后在编译程序时，通过添加bpf_load.o作为依赖库，并合并为最终的可执行文件中，这样在程序运行起来时，就可以通过声明SEC("maps")即可完成创建BPF Map的行为了。

从上面梳理的过程可以看到，这个简化版虽然使用了语法糖，但最后还是会去使用 bpf() 函数完成系统调用。

数据结构

本小节将介绍 eBPF Map 的几种常见的数据结构，包括其使用场景和使用方法。

Hash Table

对于 BPF_MAP_TYPE_HASH 类型的 eBPF Map，其 key 和 value 都是可自定义的数据结构，使用方法如下所示：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// define the struct for the key of bpf map
struct pair {
  __u32 src_ip;
  __u32 dest_ip;
};

struct stats {
  __u64 tx_cnt; // the sending request count
  __u64 rx_cnt; // the received request count
  __u64 tx_bytes; // the sending request bytes
  __u64 rx_bytes; // the sending received bytes
};

struct bpf_map_def SEC("maps") tracker_map = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(struct pair),
    .value_size = sizeof(struct stats),
    .max_entries = 2048,
};


struct stats *stats, newstats = {0, 0, 0, 0};

stats = bpf_map_lookup_elem(&tracker_map, pair);
if (stats)
{
    stats->rx_cnt++;
    stats->rx_bytes += bytes;
} else {
    newstats.rx_cnt = 1;
    newstats.rx_bytes = bytes;
    bpf_map_update_elem(&tracker_map, pair, &newstats, BPF_NOEXIST);
}

Array

对于 BPF_MAP_TYPE_ARRAY 类型的 eBPF Map，有以下特性：

• 它的 key 是作为一个数组的索引，只能是 4 个字节
• 在 Array 初始化的时候，Array 中所有的元素都 pre-allocated 并且初始化未 0
• map_delete_elem() 函数会返回 EINVAL，因为 Array 中的元素不能够被删除
• map_update_elem() 函数更新元素的时候是 non-atomic 的，并没有并发保护

BPF_MAP_TYPE_ARRAY 类型的 eBPF Map 主要用于以下两种情景：

• 全局变量：可以申请一个只有一个元素的 Array，key = 0，value 是一些全局变量的集合

• aggregation of tracing events into fixed set of buckets

下面展示了使用 BPF_MAP_TYPE_ARRAY 作为全局变量的方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

struct globals {
    u64 lat_ave;
    u64 lat_sum;
    u64 missed;
    u64 max_lat;
    int num_samples;
};

struct bpf_map_def SEC("maps") global_map = {
    .type = BPF_MAP_TYPE_ARRAY,
    .key_size = sizeof(int),
    .value_size = sizeof(struct globals),
    .max_entries = 1,
};

int bpf_prog(struct bpf_context *ctx)
{
    ...
    int ind = 0;
    struct globals *g = bpf_map_lookup_elem(&global_map, &ind);
    if (!g)
            return 0;
    if (g->lat_ave == 0) {
            g->num_samples++;
            g->lat_sum += delta;
            if (g->num_samples >= 100) {
                    g->lat_ave = g->lat_sum / g->num_samples;
    ...

Prog Array

BPF_MAP_TYPE_PROG_ARRAY 类型的 eBPF Map 主要用于尾调用，尾调用执行涉及两个步骤：

• 设置类型为 BPF_MAP_TYPE_PROG_ARRAY 的 map，这个 map 可以从用户空间通过 key/value 操作
• 调用辅助函数 bpf_tail_call() 如下所示，内核将这个辅助函数调用内联到一个特殊的 BPF 指令内。目前，这样的程序数组在用户空间侧是只写模式
  • 一个对程序数组的引用（a reference to the program array）
  • 一个查询 map 所用的 key。

1

long bpf_tail_call(void *ctx, struct bpf_map *prog_array_map, u32 index)

内核根据传入的文件描述符查找相关的 BPF 程序，自动替换给定的 map slot 处的程序指针。如果没有找到给定的 key 对应的 value，内核会跳过（fall through）这一步 ，继续执行 bpf_tail_call() 后面的指令。

尾调用是一个强大的功能，它可以实现：

• 通过尾调用结构化地解析网络报头
• 运行时原子地添加或替换功能，也即动态地改变 BPF 程序的执行行为

在 samples/bpf 中可以看到 BPF_MAP_TYPE_PROG_ARRAY 的使用示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

struct {
__uint(type, BPF_MAP_TYPE_PROG_ARRAY);
__uint(key_size, sizeof(u32));
__uint(value_size, sizeof(u32));
__uint(max_entries, 8);
} jmp_table SEC(".maps");

#define PARSE_VLAN 1
#define PARSE_MPLS 2
#define PARSE_IP 3
#define PARSE_IPV6 4

/* Protocol dispatch routine. It tail-calls next BPF program depending
 * on eth proto. Note, we could have used ...
 *
 *   bpf_tail_call(skb, &jmp_table, proto);
 *
 * ... but it would need large prog_array and cannot be optimised given
 * the map key is not static.
 */
static inline void parse_eth_proto(struct __sk_buff *skb, u32 proto)
{
switch (proto) {
case ETH_P_8021Q:
case ETH_P_8021AD:
bpf_tail_call(skb, &jmp_table, PARSE_VLAN);
break;
case ETH_P_MPLS_UC:
case ETH_P_MPLS_MC:
bpf_tail_call(skb, &jmp_table, PARSE_MPLS);
break;
case ETH_P_IP:
bpf_tail_call(skb, &jmp_table, PARSE_IP);
break;
case ETH_P_IPV6:
bpf_tail_call(skb, &jmp_table, PARSE_IPV6);
break;
}
}

Map In Map

eBPF 提供了两种特殊的 Map 类型，BPF_MAP_TYPE_ARRAY_OF_MAPS 和 BPF_MAP_TYPE_HASH_OF_MAPS，实现了 map-in-map，也就是 eBPF Map 中每一个 entry 的 Value 也是一个 Map，如下所示：

BPF_MAP_TYPE_ARRAY_OF_MAPS 和 BPF_MAP_TYPE_HASH_OF_MAPS 的区别在于，outer map 是一个 Array 还是 HashTable。

Create

之前的常规 eBPF Map 是在 load time 创建的，对于 map-in-map，我们需要定义一个 outer map，inner map 是在 runtime 被用户创建并插入到 outer map。outer map 定义如下所示：

1
2
3
4
5
6

struct bpf_map_def SEC("maps") outer_map = {
    .type = BPF_MAP_TYPE_HASH_OF_MAPS,
    .key_size = sizeof(__u32),
    .value_size = sizeof(__u32), // Must be u32 becuase it is inner map id
    .max_entries = 1,
};

这里需要注意：

• outer map 的 value_size 必须是 __u32，这正好是 inner map id 的大小

尽管你不需要在 BPF C 程序中定义 inner map，verifier 需要在 load time 知道 inner map 的定义。所以，在调用 bpf_object__load 前，你必须创建一个 dummy inner map 并且 通过调用 bpf_map__set_inner_map_fd 设置它的 fd 到 outer map 。注意，verifier 要求 dummy inner map 的 fd 必须在 load 之后关闭。

1
2
3
4
5
6
7
8
9
10
11

const char* outer_map_name = "outer_map";
struct bpf_map* outer_map = bpf_object__find_map_by_name(obj, outer_map_name);
int inner_map_fd = bpf_create_map(
    BPF_MAP_TYPE_HASH,  // type
    sizeof(__u32),      // key_size
    sizeof(__u32),      // value_size
    8,                  // max_entries
    0);                 // flag
bpf_map__set_inner_map_fd(outer_map, inner_map_fd);
bpf_object__load(obj);
close(inner_map_fd); // Important

Insert

Insert Into Outer Map

插入到 outer map 步骤如下：

• 创建一个新的 inner map
• 将创建的 inner map 的 fd 作为 value 插入到 outer map
• 关闭 inner map fd

1
2
3
4
5
6
7
8
9
10

int inner_map_fd = bpf_create_map_name(
    BPF_MAP_TYPE_HASH,   // type
    "hechaol_inner_map", // name
    sizeof(__u32),       // key_size
    sizeof(__u32),       // value_size
    8,                   // max_entries
    0);                  // flag
__u32 outer_key = 42;
bpf_map_update_elem(outer_map_fd, &outer_key, &inner_map_fd, 0 /* flag */);
close(inner_map_fd); // Important!

注意：

• outer map 的每一项 entry 的 value 是 the id of an inner map，但是调用 bpf_map_update_elem API 时给的参数是 the fd of the inner map
• 在插入之后你必须关闭 inner map fd 以避免内存泄漏。

Insert Into Inner Map

如前所述，outer map 的每一项 entry 的 value 是 the id of an inner map，而不是 the fd of the inner map。即使我们在调用 bpf_map_update_elem 传递的参数是 inner map fd，使用 bpf_map_lookup_elem 的时候我们的到的 value 是 inner map id，为了获得 inner map fd，可以调用 bpf_map_get_fd_by_id。拿到 inner map fd 之后，就可以像之前一样操作 inner map 了。

1
2
3
4
5
6
7
8
9

const __u32 outer_key = 42;
__u32 inner_map_id;
bpf_map_lookup_elem(outer_map_fd, &outer_key, &inner_map_id);
int inner_map_fd = bpf_map_get_fd_by_id(inner_map_id);
const __u32 inner_key = 12;
__u32 inner_value;
bpf_map_lookup_elem(inner_map_fd, &inner_key, &inner_value);
// ... Use inner_value;
close(inner_map_fd); // Important!

注意，每次调用 bpf_map_get_fd_by_id 都会返回一个新的 fd，你必须在使用之后关闭它以避免内存泄露。

Delete

对于 inner map 的删除和常规 Map 一样，可以调用 bpf_map_delete_elem：

1
2

const __u32 outer_key = 42;
bpf_map_delete_elem(outer_map_fd, &outer_key);

Perf Event Array

有时候我们期望 eBPF 程序能够通知用户态程序数据准备好了，array、hash 类型的 eBPF map 不满足此类使用场景，这时候就轮到 BPF_MAP_TYPE_PERF_EVENT_ARRAY 了。与普通 hash、array 类型有些不同，它没有 bpf_map_lookup_elem() 方法，使用的是 bpf_perf_event_output() 向用户态传递数据。它的 value_size 只能是 sizeof(u32)，代表的是 perf_event 的文件描述符；max_entries 则是 perf_event 的文件描述符数量。

有关源码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

struct msg {
__s32 seq;
__u64 cts;
__u8 comm[MAX_LENGTH];
};

struct bpf_map_def SEC("maps") map = {
.type = BPF_MAP_TYPE_PERF_EVENT_ARRAY,
.key_size = sizeof(int),
.value_size = sizeof(__u32),
.max_entries = 0,
};

SEC("kprobe/vfs_read")
int hello(struct pt_regs *ctx) {
unsigned long cts = bpf_ktime_get_ns();
struct msg val = {0};
static __u32 seq = 0;

val.seq = seq = (seq + 1) % 4294967295U;
val.cts = bpf_ktime_get_ns();
bpf_get_current_comm(val.comm, sizeof(val.comm));

bpf_perf_event_output(ctx, &map, 0, &val, sizeof(val));

return 0;
}

Note:

1. 这里的 seq 代表的是消息序列号
2. 若用户态不向内核态传递消息，PERFEVENT_ARRAY map 中的 max_entries 没有意义。该 map 向用户态传递的数据暂存在 perf ring buffer 中，而由 max_entries 指定的 map 存储空间存放的是 perf_event 文件描述符，若用户态程序不向 map 传递 perf_event 的文件描述符，其值可以为 0。用户态程序使用 bpf(BPF_MAP_UPDATE_ELEM) 将由 sys_perf_event_open() 取得的文件描述符传递给 eBPF 程序，eBPF 程序再使用 `bpf_perf_event{read, readvalue}()` 得到该文件描述符。于此有关的用法见 linux kernel 下的 [sample/bpf/tracex6{user, kern.c}](https://github.com/torvalds/linux/blob/v5.10/samples/bpf/tracex6_kern.c)。

libbpf 提供了 PERF_EVENT_ARRAY map 在用户态开箱即用的 API，它使用了 epoll 进行封装，仅需调用 perf_buffer__new()、perf_buffer__poll() 即可使用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

static void print_bpf_output(void *ctx, int cpu, void *data, __u32 size) {
struct msg *msg = data;

fprintf(stdout, "%.4f: @seq=%d @comm=%s\n",
 (float)msg->cts/1000000000ul, msg->seq, msg->comm);
}

int main(int argc, char *argv[]) {
struct perf_buffer_opts pb_opts = {};
struct perf_buffer *pb;
...

pb_opts.sample_cb = print_bpf_output;
pb = perf_buffer__new(map_fd, 8, &pb_opts);

while (true) {
perf_buffer__poll(pb, 1000);
if (stop)
break;
}
...
}

实战入门

现在我们就可以借助 BPF Map 来实现在内核空间收集网络包信息，主要包括源地址和目标地址，在用户空间展示这些信息。代码主要分两个部分：

• 一个是运行在内核空间的程序，主要功能为创建出定制版BPF Map，收集目标信息并存储至BPF Map中。
• 另一个是运行在用户空间的程序，主要功能为读取上面内核空间创建出的BPF Map里的数据，并进行格式化展示，以演示BPF Map在两者之间进行数据传递。

请注意，该程序的编译运行是基于Linux内核代码中BPF示例环境，如果你还不熟悉，可以参考 上一篇博客。

内核空间

下面首先介绍运行在内核空间的示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

#define KBUILD_MODNAME "foo"
#include <uapi/linux/bpf.h>
#include <uapi/linux/if_ether.h>
#include <uapi/linux/if_packet.h>
#include <uapi/linux/if_vlan.h>
#include <uapi/linux/ip.h>
#include <uapi/linux/in.h>
#include <uapi/linux/tcp.h>
#include <uapi/linux/udp.h>
#include "bpf_helpers.h"
#include "bpf_endian.h"
#include "xdp_ip_tracker_common.h"

#define bpf_printk(fmt, ...)                       \
    ({                                             \
        char ____fmt[] = fmt;                      \
        bpf_trace_printk(____fmt, sizeof(____fmt), \
                         ##__VA_ARGS__);           \
    })

struct bpf_map_def SEC("maps") tracker_map = {
    .type = BPF_MAP_TYPE_HASH,
    .key_size = sizeof(struct pair),
    .value_size = sizeof(struct stats),
    .max_entries = 2048,
};

static __always_inline bool parse_and_track(bool is_rx, void *data_begin, void *data_end, struct pair *pair)
{
    struct ethhdr *eth = data_begin;

    if ((void *)(eth + 1) > data_end)
        return false;

    if (eth->h_proto == bpf_htons(ETH_P_IP))
    {
        struct iphdr *iph = (struct iphdr *)(eth + 1);
        if ((void *)(iph + 1) > data_end)
            return false;

        pair->src_ip = is_rx ? iph->daddr : iph->saddr;
        pair->dest_ip = is_rx ? iph->saddr : iph->daddr;

        // update the map for track
        struct stats *stats, newstats = {0, 0, 0, 0};
        long long bytes = data_end - data_begin;

        stats = bpf_map_lookup_elem(&tracker_map, pair);
        if (stats)
        {
            if (is_rx)
            {
                stats->rx_cnt++;
                stats->rx_bytes += bytes;
            }
            else
            {
                stats->tx_cnt++;
                stats->tx_bytes += bytes;
            }
        }
        else
        {
            if (is_rx)
            {
                newstats.rx_cnt = 1;
                newstats.rx_bytes = bytes;
            }
            else
            {
                newstats.tx_cnt = 1;
                newstats.tx_bytes = bytes;
            }
            bpf_map_update_elem(&tracker_map, pair, &newstats, BPF_NOEXIST);
        }
        return true;
    }
    return false;
}

SEC("xdp_ip_tracker")
int _xdp_ip_tracker(struct xdp_md *ctx)
{
    // the struct to store the ip address as the keys of bpf map
    struct pair pair;

    bpf_printk("starting xdp ip tracker...\n");

    void *data_end = (void *)(long)ctx->data_end;
    void *data = (void *)(long)ctx->data;
    // pass if the network packet is not ipv4
    if (!parse_and_track(true, data, data_end, &pair))
        return XDP_PASS;

    return XDP_DROP;
}

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

我们先来看运行在内核空间的BPF程序代码重点内容：

• 通过SEC("maps")声明并创建了一个名为tracker_map 的BPF Map，它的类型是BPF_MAP_TYPE_HASH，它的 key 和 value 都是自定义的struct，定义在了xdp_ip_tracker_common.h头文件中，具体如下所示：

• 函数parse_and_track是对网络包进行分析和过滤，把源地址和目的地址联合起来作为BPF Map的key，把当前网络包的大小以 byte 单位记录下来，并联合网络包计数器作为BPF Map的value。对于连续的网络包，如果生成的key已经存在，就把value累加，否则就新增一对key-value存入BPF Map中。其中通过bpf_map_lookup_elem()函数来查找元素，bpf_map_update_elem()函数来新增元素。

用户空间

接下来是运行在用户空间的示例代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

#include <linux/bpf.h>
#include <linux/if_link.h>
#include <assert.h>
#include <errno.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/resource.h>
#include <arpa/inet.h>
#include <netinet/ether.h>
#include <unistd.h>
#include <time.h>
#include "bpf_load.h"
#include <bpf/bpf.h>
#include "bpf_util.h"
#include "xdp_ip_tracker_common.h"

static int ifindex = 6; // target network interface to attach, you can find it via `ip a`
static __u32 xdp_flags = 0;

// unlink the xdp program and exit
static void int_exit(int sig)
{
    printf("stopping\n");
    set_link_xdp_fd(ifindex, -1, xdp_flags);
    exit(0);
}

// An XDP program which track packets with IP address
// Usage: ./xdp_ip_tracker
int main(int argc, char **argv)
{
    char *filename = "xdp_ip_tracker_kern.o";
    // change limits
    struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
    if (setrlimit(RLIMIT_MEMLOCK, &r))
    {
        perror("setrlimit(RLIMIT_MEMLOCK, RLIM_INFINITY)");
        return 1;
    }

    // load the kernel bpf object file
    if (load_bpf_file(filename))
    {
        printf("error - bpf_log_buf: %s", bpf_log_buf);
        return 1;
    }

    // confirm the bpf prog fd is available
    if (!prog_fd[0])
    {
        printf("load_bpf_file: %s\n", strerror(errno));
        return 1;
    }

    // add signal handlers
    signal(SIGINT, int_exit);
    signal(SIGTERM, int_exit);

    // link the xdp program to the network interface
    if (set_link_xdp_fd(ifindex, prog_fd[0], xdp_flags) < 0)
    {
        printf("link set xdp fd failed\n");
        return 1;
    }

    int result;
    struct pair next_key, lookup_key = {0, 0};
    struct stats value = {};
    while (1)
    {
        sleep(2);
        // retrieve the bpf map of statistics
        while (bpf_map_get_next_key(map_fd[0], &lookup_key, &next_key) != -1)
        {
            //printf("The local ip of next key in the map is: '%d'\n", next_key.src_ip);
            //printf("The remote ip of next key in the map is: '%d'\n", next_key.dest_ip);
            struct in_addr local = {next_key.src_ip};
            struct in_addr remote = {next_key.dest_ip};
            printf("The local ip of next key in the map is: '%s'\n", inet_ntoa(local));
            printf("The remote ip of next key in the map is: '%s'\n", inet_ntoa(remote));
            
            // get the value via the key
            // TODO: change to assert
            // assert(bpf_map_lookup_elem(map_fd[0], &next_key, &value) == 0)
            result = bpf_map_lookup_elem(map_fd[0], &next_key, &value);
            if (result == 0)
            {
                // print the value
                printf("rx_cnt value read from the map: '%llu'\n", value.rx_cnt);
                printf("rx_bytes value read from the map: '%llu'\n", value.rx_bytes);
            }
            else
            {
                printf("Failed to read value from the map: %d (%s)\n", result, strerror(errno));
            }
            lookup_key = next_key;
            printf("\n\n");
        }
        printf("start a new loop...\n");
        // reset the lookup key for a fresh start
        lookup_key.src_ip = 0;
        lookup_key.dest_ip = 0;
    }

    printf("end\n");
    // unlink the xdp program
    set_link_xdp_fd(ifindex, -1, xdp_flags);
    return 0;
}

• 用户空间的代码跟一般看到的C程序的结构是一样的，都是有main函数作为入口。基本流程是，通过load_bpf_file()函数（本质就是用BPF_PROG_LOAD命令进行系统调用）加载对应内核空间的BPF程序编译出来的.o文件，这种通过编程加载BPF程序的方式，和我们之前通过命令行工具的方式相比，更具灵活性，适合实际场景中的产品分发。
• 加载完BPF程序之后，使用set_link_xdp_fd()函数 attach 到目标hook上，看函数名就知道了，这是XDP network hook。它接受的两个主要的参数是：
  • ifindex，这个是目标网卡的序号（可以通过ip a查看），我这里填写的是6，它是对应了一个docker容器的veth虚拟网络设备；
  • prog_fd[0]，这个是BPF程序加载到内存后生成的文件描述符fd。
• 有两个神奇的变量 prog_fd 和 map_fd 得说明下：
  • 它们都是定义在bpf_load.c的全局变量；
  • prog_fd是一个数组，在加载内核空间BPF程序时，一旦fd生成后，就添加到这个数组中去；
  • map_fd也是一个数组，在运行上文提到的load_maps()函数时，一旦完成创建BPF Map系统调用生成fd后，同样会添加到这个数组中去。 因此在bpf sample文件夹下的程序可以直接使用这两个变量，作为对于BPF程序和BPF Map的引用。
• 从代码 71 行开始是一个无限循环，里面是每2秒获取一下目标BPF Map的数据。获取的逻辑是通过bpf_map_get_next_key(map_fd[0], &lookup_key, &next_key)函数，map_fd[0]是你的目标BPF Map； lookup_key是需要查找的BPF Map目标key，这个参数是要主动传入的，而next_key是这个目标key相邻的下一个key，这个参数是被动赋值的。如果你想从头开始遍历BPF Map，就可以通过传入一个一定不存在的key作为lookup_key，然后next_key会被自动赋值为BPF Map中第一个key，key知道了，对应的value也就可以被读取了，直到bpf_map_get_next_key()返回为-1，即next_key没有可以被赋值的了，遍历也就完成了，这个函数工作起来是不是像一个iterator。
  通过上面两层循环，不停遍历BPF Map并打印里面的内容，一旦有新的网络包进来，也能及时获取到相关信息。

还有一段非常陌生的代码，如下所示：

1
2
3
4
5
6

struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
if (setrlimit(RLIMIT_MEMLOCK, &r))
{
   perror("setrlimit(RLIMIT_MEMLOCK, RLIM_INFINITY)");
   return 1;
}

• 这里有一个struct叫rlimit，全称是resource limit，顾名思义，它是控制应用进程能使用资源的限额。
• 常量RLIM_INFINITY看起来就是无限的意思，因此第一行代码就是定义了一个没有上限的资源配额。
• 第二行代码使用了函数setrlimit()，传入的第一个参数是一个资源规格名称——RLIMIT_MEMLOCK，即内存；第二个参数是刚才定义的无限资源配额，可以猜出这行代码的意思就是为内存资源配置了无限配额，即没有内存上限。
• 为什么要把内存限制放开呢？因为操作系统在不同的CPU架构，对于应用进程能使用的内存限制是不统一的，而不同的BPF程序需要使用到的内存资源也是可变的，比如你的BPF Map申请了很大的max_entries，那么这个BPF程序一定会使用不少的内存。因此为了成功运行BPF程序，就把对于内存的限制放开成无限了。

匿名 inode

在Unix/Linux的世界，一切皆是文件，BPF Map也不例外。从上文看到我们是可以通过文件描述符fd来访问BPF Map内的数据，因此BPF Map创建是遵循Linux文件创建的过程。实现BPF_MAP_CREATE系统调用命令的函数是map_create()，即创建BPF Map的核心函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

static int map_create(union bpf_attr *attr)
{
  int numa_node = bpf_map_attr_numa_node(attr);
  struct bpf_map *map;
  int f_flags;
  int err;

  err = CHECK_ATTR(BPF_MAP_CREATE);
  if (err)
    return -EINVAL;

  f_flags = bpf_get_file_flag(attr->map_flags);
  if (f_flags < 0)
    return f_flags;

  if (numa_node != NUMA_NO_NODE &&
      ((unsigned int)numa_node >= nr_node_ids ||
       !node_online(numa_node)))
    return -EINVAL;

  /* find map type and init map: hashtable vs rbtree vs bloom vs ... */
  map = find_and_alloc_map(attr);
  if (IS_ERR(map))
    return PTR_ERR(map);

  err = bpf_obj_name_cpy(map->name, attr->map_name);
  if (err)
    goto free_map_nouncharge;

  atomic_set(&map->refcnt, 1);
  atomic_set(&map->usercnt, 1);

  err = security_bpf_map_alloc(map);
  if (err)
    goto free_map_nouncharge;

  err = bpf_map_charge_memlock(map);
  if (err)
    goto free_map_sec;

  err = bpf_map_alloc_id(map);
  if (err)
    goto free_map;

  // assign a fd for bpf map
  err = bpf_map_new_fd(map, f_flags);
  if (err < 0) {
    /* failed to allocate fd.
     * bpf_map_put() is needed because the above
     * bpf_map_alloc_id() has published the map
     * to the userspace and the userspace may
     * have refcnt-ed it through BPF_MAP_GET_FD_BY_ID.
     */
    bpf_map_put(map);
    return err;
  }

  trace_bpf_map_create(map, err);
  return err;

free_map:
  bpf_map_uncharge_memlock(map);
free_map_sec:
  security_bpf_map_free(map);
free_map_nouncharge:
  map->ops->map_free(map);
  return err;
}

其中bpf_map_new_fd()函数就是用来为BPF Map分配fd的，下面是其函数主体：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

// https://elixir.bootlin.com/linux/v4.15/source/kernel/bpf/syscall.c#L327
int bpf_map_new_fd(struct bpf_map *map, int flags)
{
  int ret;

  ret = security_bpf_map(map, OPEN_FMODE(flags));
  if (ret < 0)
    return ret;
/**
 * anon_inode_getfd - creates a new file instance by hooking it up to an
 *                    anonymous inode, and a dentry that describe the "class"
 *                    of the file
 *
 * @name:    [in]    name of the "class" of the new file
 * @fops:    [in]    file operations for the new file
 * @priv:    [in]    private data for the new file (will be file's private_data)
 * @flags:   [in]    flags
 *
 * Creates a new file by hooking it on a single inode. This is useful for files
 * that do not need to have a full-fledged inode in order to operate correctly.
 * All the files created with anon_inode_getfd() will share a single inode,
 * hence saving memory and avoiding code duplication for the file/inode/dentry
 * setup.  Returns new descriptor or an error code.
 */
  return anon_inode_getfd("bpf-map", &bpf_map_fops, map,
        flags | O_CLOEXEC);
}

要说的是anon_inode_getfd()这个函数，它不是一般的分配 fd 的方式，是一种特殊的匿名方式，它的inode没有被绑定到磁盘上的某个文件，而是仅仅在内存里。一旦fd关闭后，对应的内存空间就会被释放，相关数据，即我们的 BPF Map也就被删除了。它的comment doc写得非常好，详细大家可以自行了解。

也可以通过lsof和cat /proc/[pid]/fd命令看到BPF Map作为 anon_inode 的效果（其实普通的BPF程序也是这个type）：

BPF Map 调试

如果想看当前操作系统上面是否有正在使用BPF Map，可以使用BPF社区大力推荐的命令行工具——BPFtool，它是专门用来查看BPF程序和BPF Map的命令行工具，并且可以对它们做一些简单操作。BPFtool源码 被维护在Linux内核代码里，因此一般都是通过make命令自行编译出可执行文件，操作起来并不麻烦，如下所示：

1
2
3
4
5

cd linux-source-code/tools
make -C  bpf/bpftool/
cd bpf/bpftool/
# the output is a binary named as `bpftool`
./bpftool [prog|map]

需要注意的是，不同内核版本下的BPFtool代码有所差异，其功能也不一样，一般来说高版本内核下的BPFtool功能更多，也是向下兼容的。我使用的就是在5.6.6内核版本下编译出来的BPFtool，并且在内核版本是4.15.0操作系统上运行顺畅。

接下来给大家简单演示如何使用bpftool查看BPF Map信息，主要用两个命令进行查看：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# command #1, list all the bpf map in the current node
# you can find map id, map type, map name, key type, value type, the number of max entry and memory allocation in the output
> bpftool map 
29: hash  name tracker_map  flags 0x0
  key 8B  value 32B  max_entries 2048  memlock 217088B


# command #2, show the bpf map details including keys and value in hex-format
# the map id can be found in the output of command #1
# you can also find the element number
> bpftool map dump id [map id]
key:
c0 a8 3a 01 ac 11 00 02
value:
00 00 00 00 00 00 00 00  0a 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  e4 02 00 00 00 00 00 00
key:
ac 11 00 01 ac 11 00 02
value:
00 00 00 00 00 00 00 00  07 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00  06 02 00 00 00 00 00 00
Found 2 elements

参考资料

• BPF数据传递的桥梁——BPF MAP
• Linux Kernel Patch, bpf: add hashtable type of eBPF maps, v3.19-rc1
• Linux Kernel Patch, bpf: add array type of eBPF maps, v3.19-rc1
• Linux Kernel Patch, bpf: allow bpf programs to tail-call other bpf programs, v4.2-rc1
• Linux Kernel Patch, bpf: Add new bpf map type to store the pointer to struct perf_event, v4.3-rc1
• Linux Kernel Patch, bpf: introduce BPF_MAP_TYPE_PERCPU_HASH map, v4.6-rc1
• Linux Kernel Patch, bpf: introduce BPF_MAP_TYPE_PERCPU_ARRAY map, v4.6-rc1
• Linux Kernel Patch, bpf: Add hash of maps support
• Use Map-in-Map in BPF programs via Libbpf

eBPF 源于 BPF，本质上是处于内核中的一个高效与灵活的虚类虚拟机组件，以一种安全的方式在许多内核 hook 点执行字节码。BPF 最初的目的是用于高效网络报文过滤，经过重新设计，eBPF 不再局限于网络协议栈，已经成为内核顶级的子系统，演进为一个通用执行引擎。开发者可基于 eBPF 开发性能分析工具、软件定义网络、安全等诸多场景。本文将介绍 eBPF 的前世今生，并构建一个 eBPF 环境进行开发实践，文中所有的代码可以在我的 Github 中找到。

技术背景

发展历史

BPF，是类 Unix 系统上数据链路层的一种原始接口，提供原始链路层封包的收发。1992 年，Steven McCanne 和 Van Jacobson 写了一篇名为 The BSD Packet Filter: A New Architecture for User-level Packet Capture 的论文。在文中，作者描述了他们如何在 Unix 内核实现网络数据包过滤，这种新的技术比当时最先进的数据包过滤技术快 20 倍。

BPF 在数据包过滤上引入了两大革新：

• 一个新的虚拟机 (VM) 设计，可以有效地工作在基于寄存器结构的 CPU 之上
• 应用程序使用缓存只复制与过滤数据包相关的数据，不会复制数据包的所有信息，这样可以最大程度地减少BPF 处理的数据

由于这些巨大的改进，所有的 Unix 系统都选择采用 BPF 作为网络数据包过滤技术，直到今天，许多 Unix 内核的派生系统中（包括 Linux 内核）仍使用该实现。tcpdump 的底层采用 BPF 作为底层包过滤技术，我们可以在命令后面增加 -d 来查看 tcpdump 过滤条件的底层汇编指令。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$ tcpdump -d 'ip and tcp port 8080'
(000) ldh      [12]
(001) jeq      #0x800           jt 2jf 12
(002) ldb      [23]
(003) jeq      #0x6             jt 4jf 12
(004) ldh      [20]
(005) jset     #0x1fff          jt 12jf 6
(006) ldxb     4*([14]&0xf)
(007) ldh      [x + 14]
(008) jeq      #0x1f90          jt 11jf 9
(009) ldh      [x + 16]
(010) jeq      #0x1f90          jt 11jf 12
(011) ret      #262144
(012) ret      #0

2014 年初，Alexei Starovoitov 实现了 eBPF（extended Berkeley Packet Filter）。经过重新设计，eBPF 演进为一个通用执行引擎，可基于此开发性能分析工具、软件定义网络等诸多场景。eBPF 最早出现在 3.18 内核中，此后原来的 BPF 就被称为经典 BPF，缩写 cBPF（classic BPF），cBPF 现在已经基本废弃。现在，Linux 内核只运行 eBPF，内核会将加载的 cBPF 字节码透明地转换成 eBPF 再执行。

eBPF 与 cBPF

eBPF 新的设计针对现代硬件进行了优化，所以 eBPF 生成的指令集比旧的 BPF 解释器生成的机器码执行得更快。扩展版本也增加了虚拟机中的寄存器数量，将原有的 2 个 32 位寄存器增加到 10 个 64 位寄存器。由于寄存器数量和宽度的增加，开发人员可以使用函数参数自由交换更多的信息，编写更复杂的程序。总之，这些改进使 eBPF 版本的速度比原来的 BPF 提高了 4 倍。

2014 年 6 月，eBPF 扩展到用户空间，这也成为了 BPF 技术的转折点。 正如 Alexei 在提交补丁的注释中写到：「这个补丁展示了 eBPF 的潜力」。当前，eBPF 不再局限于网络栈，已经成为内核顶级的子系统。

eBPF 与内核模块

对比 Web 的发展，eBPF 与内核的关系有点类似于 JavaScript 与浏览器内核的关系，eBPF 相比于直接修改内核和编写内核模块提供了一种新的内核可编程的选项。eBPF 程序架构强调安全性和稳定性，看上去更像内核模块，但与内核模块不同，eBPF 程序不需要重新编译内核，并且可以确保 eBPF 程序运行完成，而不会造成系统的崩溃。

eBPF 架构

eBPF 分为用户空间程序和内核程序两部分：

• 用户空间程序负责加载 BPF 字节码至内核，如需要也会负责读取内核回传的统计信息或者事件详情
• 内核中的 BPF 字节码负责在内核中执行特定事件，如需要也会将执行的结果通过 maps 或者 perf-event 事件发送至用户空间
• 其中用户空间程序与内核 BPF 字节码程序可以使用 map 结构实现双向通信，这为内核中运行的 BPF 字节码程序提供了更加灵活的控制

eBPF 整体结构图如下：

用户空间程序与内核中的 BPF 字节码交互的流程主要如下：

1. 使用 LLVM 或者 GCC 工具将编写的 BPF 代码程序编译成 BPF 字节码
2. 使用加载程序 Loader 将字节码加载至内核
3. 内核使用验证器（Verfier） 组件保证执行字节码的安全性，以避免对内核造成灾难，在确认字节码安全后将其加载对应的内核模块执行
4. 内核中运行的 BPF 字节码程序可以使用两种方式将数据回传至用户空间
   • maps 方式可用于将内核中实现的统计摘要信息（比如测量延迟、堆栈信息）等回传至用户空间；
   • perf-event 用于将内核采集的事件实时发送至用户空间，用户空间程序实时读取分析；

eBPF 限制

eBPF 技术虽然强大，但是为了保证内核的处理安全和及时响应，内核中的 eBPF 技术也给予了诸多限制，当然随着技术的发展和演进，限制也在逐步放宽或者提供了对应的解决方案。

• eBPF 程序不能调用任意的内核参数，只限于内核模块中列出的 BPF Helper 函数，函数支持列表也随着内核的演进在不断增加。

• eBPF 程序不允许包含无法到达的指令，防止加载无效代码，延迟程序的终止。

• eBPF 程序中循环次数限制且必须在有限时间内结束，这主要是用来防止在 kprobes 中插入任意的循环，导致锁住整个系统；解决办法包括展开循环，并为需要循环的常见用途添加辅助函数。Linux 5.3 在 BPF 中包含了对有界循环的支持，它有一个可验证的运行时间上限。

• eBPF 堆栈大小被限制在 MAX_BPF_STACK，截止到内核 Linux 5.8 版本，被设置为 512；参见 include/linux/filter.h，这个限制特别是在栈上存储多个字符串缓冲区时：一个char[256]缓冲区会消耗这个栈的一半。目前没有计划增加这个限制，解决方法是改用 bpf 映射存储，它实际上是无限的。

  1 2	/* BPF program can access up to 512 bytes of stack space. */ #define MAX_BPF_STACK512

• eBPF 字节码大小最初被限制为 4096 条指令，截止到内核 Linux 5.8 版本， 当前已将放宽至 100 万指令（ BPF_COMPLEXITY_LIMIT_INSNS），参见：include/linux/bpf.h，对于无权限的BPF程序，仍然保留4096条限制 ( BPF_MAXINSNS )；新版本的 eBPF 也支持了多个 eBPF 程序级联调用，虽然传递信息存在某些限制，但是可以通过组合实现更加强大的功能。

  1	#define BPF_COMPLEXITY_LIMIT_INSNS 1000000 /* yes. 1M insns */

eBPF 实战

在深入介绍 eBPF 特性之前，让我们 Get Hands Dirty，切切实实的感受 eBPF 程序到底是什么，我们该如何开发 eBPF 程序。随着 eBPF 生态的演进，现在已经有越来越多的工具链用于开发 eBPF 程序，在后文也会详细介绍：

• 基于 bcc 开发：bcc 提供了对 eBPF 开发，前段提供 Python API，后端 eBPF 程序通过 C 实现。特点是简单易用，但是性能较差。
• 基于 libebpf-bootstrap 开发：libebpf-bootstrap 提供了一个方便的脚手架
• 基于内核源码开发：内核源码开发门槛较高，但是也更加切合 eBPF 底层原理，所以这里以这个方法作为示例

内核源码编译

系统环境如下，采用腾讯云 CVM，Ubuntu 20.04，内核版本 5.4.0

1
2

$ uname -a
Linux VM-1-3-ubuntu 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

首先安装必要依赖：

1
2
3

sudo apt install -y bison build-essential cmake flex git libedit-dev pkg-config libmnl-dev \
   python zlib1g-dev libssl-dev libelf-dev libcap-dev libfl-dev llvm clang pkg-config \
   gcc-multilib luajit libluajit-5.1-dev libncurses5-dev libclang-dev clang-tools

一般情况下推荐采用 apt 方式的安装源码，安装简单而且只安装当前内核的源码，源码的大小在 200M 左右。

1
2
3

# apt-cache search linux-source

# apt install linux-source-5.4.0

源码安装至 /usr/src/ 目录下。

1
2
3
4
5
6
7
8
9
10
11
12

$ ls -hl
total 4.0K
drwxr-xr-x 4 root root 4.0K Nov  9 13:22 linux-source-5.4.0
lrwxrwxrwx 1 root root   45 Oct 15 10:28 linux-source-5.4.0.tar.bz2 -> linux-source-5.4.0/linux-source-5.4.0.tar.bz2
$ tar -jxvf linux-source-5.4.0.tar.bz2
$ cd linux-source-5.4.0

$ cp -v /boot/config-$(uname -r) .config # make defconfig 或者 make menuconfig
$ make headers_install
$ make modules_prepare
$ make scripts     # 可选
$ make M=samples/bpf  # 如果配置出错，可以使用 make oldconfig && make prepare 修复

编译成功后，可以在 samples/bpf 目录下看到一系列的目标文件和二进制文件。

Hello World

前面说到 eBPF 通常由内核空间程序和用户空间程序两部分组成，现在 samples/bpf 目录下有很多这种程序，内核空间程序以 _kern.c 结尾，用户空间程序以 _user.c 结尾。先不看这些复杂的程序，我们手动写一个 eBPF 程序的 Hello World。

内核中的程序 hello_kern.c：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

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

#define SEC(NAME) __attribute__((section(NAME), used))

SEC("tracepoint/syscalls/sys_enter_execve")
int bpf_prog(void *ctx)
{
    char msg[] = "Hello BPF from houmin!\n";
    bpf_trace_printk(msg, sizeof(msg));
    return 0;
}

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

函数入口

上述代码和普通的C语言编程有一些区别。

1. 程序的入口通过编译器的 pragama __section("tracepoint/syscalls/sys_enter_execve") 指定的。
2. 入口的参数不再是 argc, argv, 它根据不同的 prog type 而有所差别。我们的例子中，prog type 是 BPF_PROG_TYPE_TRACEPOINT， 它的入口参数就是 void *ctx。

头文件

#include <linux/bpf.h>

这个头文件的来源是kernel source header file 。它安装在 /usr/include/linux/bpf.h中。

它提供了bpf 编程需要的很多symbol。例如

1. enum bpf_func_id 定义了所有的kerne helper function 的id
2. enum bpf_prog_type 定义了内核支持的所有的prog 的类型。
3. struct __sk_buff 是bpf 代码中访问内核struct sk_buff的接口。

等等

#include “bpf_helpers.h”

来自libbpf ，需要自行安装。 我们引用这个头文件是因为调用了bpf_printk()。这是一个kernel helper function。

程序解释

这里我们简单解读下内核态的 ebpf 程序，非常简单：

• bpf_trace_printk 是一个 eBPF helper 函数，用于打印信息到 trace_pipe (/sys/kernel/debug/tracing/trace_pipe)，详见这里
• 代码声明了 SEC 宏，并且定义了 GPL 的 License，这是因为加载进内核的 eBPF 程序需要有 License 检查，类似于内核模块

加载 BPF 代码

用户态程序 hello_user.c

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include <stdio.h>
#include "bpf_load.h"

int main(int argc, char **argv)
{
    if(load_bpf_file("hello_kern.o") != 0)
    {
        printf("The kernel didn't load BPF program\n");
        return -1;
    }

    read_trace_pipe();
    return 0;
}

在用户态 ebpf 程序中，解读如下：

• 通过 load_bpf_file 将编译出的内核态 ebpf 目标文件加载到内核
• 通过 read_trace_pipe 从 trace_pipe 读取 trace 信息，打印到控制台中

修改 samples/bpf 目录下的 Makefile 文件，在对应的位置添加以下三行：

1
2
3

hostprogs-y += hello
hello-objs := bpf_load.o hello_user.o
always += hello_kern.o

重新编译，可以看到编译成功的文件

1
2
3
4
5
6
7

$ make M=samples/bpf
$ ls -hl samples/bpf/hello*
-rwxrwxr-x 1 ubuntu ubuntu 404K Mar 30 17:48 samples/bpf/hello
-rw-rw-r-- 1 ubuntu ubuntu  317 Mar 30 17:47 samples/bpf/hello_kern.c
-rw-rw-r-- 1 ubuntu ubuntu 3.8K Mar 30 17:48 samples/bpf/hello_kern.o
-rw-rw-r-- 1 ubuntu ubuntu  246 Mar 30 17:47 samples/bpf/hello_user.c
-rw-rw-r-- 1 ubuntu ubuntu 2.2K Mar 30 17:48 samples/bpf/hello_user.o

进入到对应的目录运行 hello 程序，可以看到输出结果如下：

1
2
3
4
5
6

$ sudo ./hello
           <...>-102735 [001] ....  6733.481740: 0: Hello BPF from houmin!

           <...>-102736 [000] ....  6733.482884: 0: Hello BPF from houmin!

           <...>-102737 [002] ....  6733.483074: 0: Hello BPF from houmin!

代码解读

前面提到 load_bpf_file 函数将 LLVM 编译出来的 eBPF 字节码加载进内核，这到底是如何实现的呢？

• 经过搜查，可以看到 load_bpf_file 也是在 samples/bpf 目录下实现的，具体的参见 bpf_load.c
• 阅读 load_bpf_file 代码可以看到，它主要是解析 ELF 格式的 eBPF 字节码，然后调用 load_and_attach 函数
• 在 load_and_attach 函数中，我们可以看到其调用了 bpf_load_program 函数，这是 libbpf 提供的函数。
• 调用的 bpf_load_program 中的 license、kern_version 等参数来自于解析 eBPF ELF 文件，prog_type 来自于 bpf 代码里面 SEC 字段指定的类型。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
{
  bool is_socket = strncmp(event, "socket", 6) == 0;
bool is_kprobe = strncmp(event, "kprobe/", 7) == 0;
bool is_kretprobe = strncmp(event, "kretprobe/", 10) == 0;
bool is_tracepoint = strncmp(event, "tracepoint/", 11) == 0;
bool is_raw_tracepoint = strncmp(event, "raw_tracepoint/", 15) == 0;
bool is_xdp = strncmp(event, "xdp", 3) == 0;
bool is_perf_event = strncmp(event, "perf_event", 10) == 0;
bool is_cgroup_skb = strncmp(event, "cgroup/skb", 10) == 0;
bool is_cgroup_sk = strncmp(event, "cgroup/sock", 11) == 0;
bool is_sockops = strncmp(event, "sockops", 7) == 0;
bool is_sk_skb = strncmp(event, "sk_skb", 6) == 0;
bool is_sk_msg = strncmp(event, "sk_msg", 6) == 0;
  
  //...
  
fd = bpf_load_program(prog_type, prog, insns_cnt, license, kern_version,
      bpf_log_buf, BPF_LOG_BUF_SIZE);
if (fd < 0) {
printf("bpf_load_program() err=%d\n%s", errno, bpf_log_buf);
return -1;
}
  //...
}

eBPF 特性

Hook Overview

eBPF 程序都是事件驱动的，它们会在内核或者应用程序经过某个确定的 Hook 点的时候运行，这些 Hook 点都是提前定义的，包括系统调用、函数进入/退出、内核 tracepoints、网络事件等。

如果针对某个特定需求的 Hook 点不存在，可以通过 kprobe 或者 uprobe 来在内核或者用户程序的几乎所有地方挂载 eBPF 程序。

Verification

With great power there must also come great responsibility.

每一个 eBPF 程序加载到内核都要经过 Verification，用来保证 eBPF 程序的安全性，主要包括：

• 要保证 加载 eBPF 程序的进程有必要的特权级，除非节点开启了 unpriviledged 特性，只有特权级的程序才能够加载 eBPF 程序

  • 内核提供了一个配置项 /proc/sys/kernel/unprivileged_bpf_disabled 来禁止非特权用户使用 bpf(2) 系统调用，可以通过 sysctl 命令修改

  • 比较特殊的一点是，这个配置项特意设计为一次性开关（one-time kill switch）， 这意味着一旦将它设为 1，就没有办法再改为 0 了，除非重启内核

  • 一旦设置为 1 之后，只有初始命名空间中有 CAP_SYS_ADMIN 特权的进程才可以调用 bpf(2) 系统调用 。 Cilium 启动后也会将这个配置项设为 1：

    1	$ echo 1 > /proc/sys/kernel/unprivileged_bpf_disabled

• 要保证 eBPF 程序不会崩溃或者使得系统出故障

• 要保证 eBPF 程序不能陷入死循环，能够 runs to completion

• 要保证 eBPF 程序必须满足系统要求的大小，过大的 eBPF 程序不允许被加载进内核

• 要保证 eBPF 程序的复杂度有限，Verifier 将会评估 eBPF 程序所有可能的执行路径，必须能够在有限时间内完成 eBPF 程序复杂度分析

JIT Compilation

Just-In-Time(JIT) 编译用来将通用的 eBPF 字节码翻译成与机器相关的指令集，从而极大加速 BPF 程序的执行：

• 与解释器相比，它们可以降低每个指令的开销。通常，指令可以 1:1 映射到底层架构的原生指令
• 这也会减少生成的可执行镜像的大小，因此对 CPU 的指令缓存更友好
• 特别地，对于 CISC 指令集（例如 x86），JIT 做了很多特殊优化，目的是为给定的指令产生可能的最短操作码，以降低程序翻译过程所需的空间

64 位的 x86_64、arm64、ppc64、s390x、mips64、sparc64 和 32 位的 arm 、x86_32 架构都内置了 in-kernel eBPF JIT 编译器，它们的功能都是一样的，可以用如下方式打开：

1

$ echo 1 > /proc/sys/net/core/bpf_jit_enable

32 位的 mips、ppc 和 sparc 架构目前内置的是一个 cBPF JIT 编译器。这些只有 cBPF JIT 编译器的架构，以及那些甚至完全没有 BPF JIT 编译器的架构，需要通过内核中的解释器（in-kernel interpreter）执行 eBPF 程序。

要判断哪些平台支持 eBPF JIT，可以在内核源文件中 grep HAVE_EBPF_JIT：

1
2
3
4
5
6
7
8

$ git grep HAVE_EBPF_JIT arch/
arch/arm/Kconfig:       select HAVE_EBPF_JIT   if !CPU_ENDIAN_BE32
arch/arm64/Kconfig:     select HAVE_EBPF_JIT
arch/powerpc/Kconfig:   select HAVE_EBPF_JIT   if PPC64
arch/mips/Kconfig:      select HAVE_EBPF_JIT   if (64BIT && !CPU_MICROMIPS)
arch/s390/Kconfig:      select HAVE_EBPF_JIT   if PACK_STACK && HAVE_MARCH_Z196_FEATURES
arch/sparc/Kconfig:     select HAVE_EBPF_JIT   if SPARC64
arch/x86/Kconfig:       select HAVE_EBPF_JIT   if X86_64

Maps

BPF Map 是驻留在内核空间中的高效 Key/Value store，包含多种类型的 Map，由内核实现其功能，具体实现可以参考 我的这篇博文。

BPF Map 的交互场景有以下几种：

• BPF 程序和用户态程序的交互：BPF 程序运行完，得到的结果存储到 map 中，供用户态程序通过文件描述符访问
• BPF 程序和内核态程序的交互：和 BPF 程序以外的内核程序交互，也可以使用 map 作为中介
• BPF 程序间交互：如果 BPF 程序内部需要用全局变量来交互，但是由于安全原因 BPF 程序不允许访问全局变量，可以使用 map 来充当全局变量
• BPF Tail call：Tail call 是一个BPF程序跳转到另一BPF程序，BPF程序首先通过 BPF_MAP_TYPE_PROG_ARRAY 类型的 map 来知道另一个BPF程序的指针，然后调用 tail_call() 的 helper function 来执行Tail call

共享 map 的 BPF 程序不要求是相同的程序类型，例如 tracing 程序可以和网络程序共享 map，单个 BPF 程序目前最多可直接访问 64 个不同 map。

当前可用的 通用 map 有：

• BPF_MAP_TYPE_HASH
• BPF_MAP_TYPE_ARRAY
• BPF_MAP_TYPE_PERCPU_HASH
• BPF_MAP_TYPE_PERCPU_ARRAY
• BPF_MAP_TYPE_LRU_HASH
• BPF_MAP_TYPE_LRU_PERCPU_HASH
• BPF_MAP_TYPE_LPM_TRIE

以上 map 都使用相同的一组 BPF 辅助函数来执行查找、更新或删除操作，但各自实现了不同的后端，这些后端各有不同的语义和性能特点。随着多CPU架构的成熟发展，BPF Map也引入了 per-cpu 类型，如BPF_MAP_TYPE_PERCPU_HASH、BPF_MAP_TYPE_PERCPU_ARRAY等，当你使用这种类型的BPF Map时，每个CPU都会存储并看到它自己的Map数据，从属于不同CPU之间的数据是互相隔离的，这样做的好处是，在进行查找和聚合操作时更加高效，性能更好，尤其是你的BPF程序主要是在做收集时间序列型数据，如流量数据或指标等。

当前内核中的 非通用 map 有：

• BPF_MAP_TYPE_PROG_ARRAY：一个数组 map，用于 hold 其他的 BPF 程序
• BPF_MAP_TYPE_PERF_EVENT_ARRAY
• BPF_MAP_TYPE_CGROUP_ARRAY：用于检查skb中的cgroup2成员信息
• BPF_MAP_TYPE_STACK_TRACE：用于存储栈跟踪的MAP
• BPF_MAP_TYPE_ARRAY_OF_MAPS：持有（hold） 其他 map 的指针，这样整个 map 就可以在运行时实现原子替换
• BPF_MAP_TYPE_HASH_OF_MAPS：持有（hold） 其他 map 的指针，这样整个 map 就可以在运行时实现原子替换

Helper Calls

eBPF 程序不能够随意调用内核函数，如果这么做的话会导致 eBPF 程序与特定的内核版本绑定，相反它内核定义的一系列 Helper functions。 Helper functions 使得 BPF 能够通过一组内核定义的稳定的函数调用来从内核中查询数据，或者将数据推送到内核。所有的 BPF 辅助函数都是核心内核的一部分，无法通过内核模块来扩展或添加。当前可用的 BPF 辅助函数已经有几十个，并且数量还在不断增加，你可以在 Linux Manual Page: bpf-helpers 看到当前 Linux 支持的 Helper functions。

不同类型的 BPF 程序能够使用的辅助函数可能是不同的，例如:

• 与 attach 到 tc 层的 BPF 程序相比，attach 到 socket 的 BPF程序只能够调用前者可以调用的辅助函数的一个子集
• lightweight tunneling 使用的封装和解封装辅助函数，只能被更低的 tc 层使用；而推送通知到用户态所使用的事件输出辅助函数，既可以被 tc 程序使用也可以被 XDP 程序使用

所有的辅助函数都共享同一个通用的、和系统调用类似的函数方法，其定义如下：

1

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

内核将辅助函数抽象成 BPF_CALL_0() 到 BPF_CALL_5() 几个宏，形式和相应类型的系统调用类似，这里宏的定义可以参见 include/linux/filter.h 。以 bpf_map_update_elem 为例，可以看到它通过调用相应 map 的回调函数完成更新 map 元素的操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

BPF_CALL_4(bpf_map_update_elem, struct bpf_map *, map, void *, key,
           void *, value, u64, flags)
{
    WARN_ON_ONCE(!rcu_read_lock_held());
    return map->ops->map_update_elem(map, key, value, flags);
}

const struct bpf_func_proto bpf_map_update_elem_proto = {
    .func           = bpf_map_update_elem,
    .gpl_only       = false,
    .ret_type       = RET_INTEGER,
    .arg1_type      = ARG_CONST_MAP_PTR,
    .arg2_type      = ARG_PTR_TO_MAP_KEY,
    .arg3_type      = ARG_PTR_TO_MAP_VALUE,
    .arg4_type      = ARG_ANYTHING,
};

这种方式有很多优点：

虽然 cBPF 允许其加载指令（load instructions）进行超出范围的访问（overload），以便从一个看似不可能的包偏移量（packet offset）获取数据以唤醒多功能辅助函数，但每个 cBPF JIT 仍然需要为这个 cBPF 扩展实现对应的支持。而在 eBPF 中，JIT 编译器会以一种透明和高效的方式编译新加入的辅助函数，这意味着 JIT 编 译器只需要发射（emit）一条调用指令（call instruction），因为寄存器映射的方式使得 BPF 排列参数的方式（assignments）已经和底层架构的调用约定相匹配了。这使得基于辅助函数扩展核心内核（core kernel）非常方便。所有的 BPF 辅助函数都是核心内核的一部分，无法通过内核模块（kernel module）来扩展或添加。

前面提到的函数签名还允许校验器执行类型检测（type check）。上面的 struct bpf_func_proto 用于存放校验器必需知道的所有关于该辅助函数的信息，这 样校验器可以确保辅助函数期望的类型和 BPF 程序寄存器中的当前内容是匹配的。

参数类型范围很广，从任意类型的值，到限制只能为特定类型，例如 BPF 栈缓冲区（stack buffer）的 pointer/size 参数对，辅助函数可以从这个位置读取数据或向其写入数据。 对于这种情况，校验器还可以执行额外的检查，例如，缓冲区是否已经初始化过了。

Tail Calls

尾调用的机制是指：一个 BPF 程序可以调用另一个 BPF 程序，并且调用完成后不用返回到原来的程序。

• 和普通函数调用相比，这种调用方式开销最小，因为它是用长跳转（long jump）实现的，复用了原来的栈帧 （stack frame）
• BPF 程序都是独立验证的，因此要传递状态，要么使用 per-CPU map 作为 scratch 缓冲区 ，要么如果是 tc 程序的话，还可以使用 skb 的某些字段（例如 cb[]）
• 相同类型的程序才可以尾调用，而且它们还要与 JIT 编译器相匹配，因此要么是 JIT 编译执行，要么是解释器执行（invoke interpreted programs），但不能同时使用两种方式

BPF to BPF Calls

除了 BPF 辅助函数和 BPF 尾调用之外，BPF 核心基础设施最近刚加入了一个新特性：BPF to BPF calls。在这个特性引入内核之前，典型的 BPF C 程序必须 将所有需要复用的代码进行特殊处理，例如，在头文件中声明为 always_inline。当 LLVM 编译和生成 BPF 对象文件时，所有这些函数将被内联，因此会在生成的对象文件中重 复多次，导致代码尺寸膨胀：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#include <linux/bpf.h>

#ifndef __section
# define __section(NAME)                  \
   __attribute__((section(NAME), used))
#endif

#ifndef __inline
# define __inline                         \
   inline __attribute__((always_inline))
#endif

static __inline int foo(void)
{
    return XDP_DROP;
}

__section("prog")
int xdp_drop(struct xdp_md *ctx)
{
    return foo();
}

char __license[] __section("license") = "GPL";

之所以要这样做是因为 BPF 程序的加载器、校验器、解释器和 JIT 中都缺少对函数调用的支持。从 Linux 4.16 和 LLVM 6.0 开始，这个限制得到了解决，BPF 程序不再需要到处使用 always_inline 声明了。因此，上面的代码可以更自然地重写为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#include <linux/bpf.h>

#ifndef __section
# define __section(NAME)                  \
   __attribute__((section(NAME), used))
#endif

static int foo(void)
{
    return XDP_DROP;
}

__section("prog")
int xdp_drop(struct xdp_md *ctx)
{
    return foo();
}

char __license[] __section("license") = "GPL";

BPF 到 BPF 调用是一个重要的性能优化，极大减小了生成的 BPF 代码大小，因此 对 CPU 指令缓存（instruction cache，i-cache）更友好。

BPF 辅助函数的调用约定也适用于 BPF 函数间调用：

• r1 - r5 用于传递参数，返回结果放到 r0
• r1 - r5 是 scratch registers，r6 - r9 像往常一样是保留寄存器
• 最大嵌套调用深度是 8
• 调用方可以传递指针（例如，指向调用方的栈帧的指针） 给被调用方，但反过来不行

当前，BPF 函数间调用和 BPF 尾调用是不兼容的，因为后者需要复用当前的栈设置（ stack setup），而前者会增加一个额外的栈帧，因此不符合尾调用期望的布局。

BPF JIT 编译器为每个函数体发射独立的镜像（emit separate images for each function body），稍后在最后一通 JIT 处理（final JIT pass）中再修改镜像中函数调用的地址 。已经证明，这种方式需要对各种 JIT 做最少的修改，因为在实现中它们可以将 BPF 函数间调用当做常规的 BPF 辅助函数调用。

Object Pinning

BPF map 和程序作为内核资源只能通过文件描述符访问，其背后是内核中的匿名 inode。这带来了很多优点：

• 用户空间应用程序能够使用大部分文件描述符相关的 API
• 传递给 Unix socket 的文件描述符是透明工作等等

但同时，文件描述符受限于进程的生命周期，使得 map 共享之类的操作非常笨重，这给某些特定的场景带来了很多复杂性。

例如 iproute2，其中的 tc 或 XDP 在准备环境、加载程序到内核之后最终会退出。在这种情况下，从用户空间也无法访问这些 map 了，而本来这些 map 其实是很有用的。例如，在 data path 的 ingress 和 egress 位置共享的 map（可以统计包数、字节数、PPS 等信息）。另外，第三方应用可能希望在 BPF 程序运行时监控或更新 map。

为了解决这个问题，内核实现了一个最小内核空间 BPF 文件系统，BPF map 和 BPF 程序 都可以 pin 到这个文件系统内，这个过程称为 object pinning。BPF 相关的文件系统不是单例模式（singleton），它支持多挂载实例、硬链接、软连接等等。

相应的，BPF 系统调用扩展了两个新命令，如下图所示：

• BPF_OBJ_PIN：钉住一个对象
• BPF_OBJ_GET：获取一个被钉住的对象

Hardening

Protection Execution Protection

为了避免代码被损坏，BPF 会在程序的生命周期内，在内核中将 BPF 解释器解释后的整个镜像（struct bpf_prog）和 JIT 编译之后的镜像（struct bpf_binary_header）锁定为只读的。在这些位置发生的任何数据损坏（例如由于某些内核 bug 导致的）会触发通用的保护机制，因此会造成内核崩溃而不是允许损坏静默地发生。

查看哪些平台支持将镜像内存（image memory）设置为只读的，可以通过下面的搜索：

1
2
3
4
5

$ git grep ARCH_HAS_SET_MEMORY | grep select
arch/arm/Kconfig:    select ARCH_HAS_SET_MEMORY
arch/arm64/Kconfig:  select ARCH_HAS_SET_MEMORY
arch/s390/Kconfig:   select ARCH_HAS_SET_MEMORY
arch/x86/Kconfig:    select ARCH_HAS_SET_MEMORY

CONFIG_ARCH_HAS_SET_MEMORY 选项是不可配置的，因此平台要么内置支持，要么不支持，那些目前还不支持的架构未来可能也会支持。

Mitigation Against Spectre

为了防御 Spectre v2) 攻击，Linux 内核提供了 CONFIG_BPF_JIT_ALWAYS_ON 选项，打开这个开关后 BPF 解释器将会从内核中完全移除，永远启用 JIT 编译器：

• 如果应用在一个基于虚拟机的环境，客户机内核将不会复用内核的 BPF 解释器，因此可以避免某些相关的攻击
• 如果是基于容器的环境，这个配置是可选的，如果 JIT 功能打开了，解释器仍然可能会在编译时被去掉，以降低内核的复杂度
• 对于主流架构（例如 x86_64 和 arm64）上的 JIT 通常都建议打开这个开关

将 /proc/sys/net/core/bpf_jit_harden 设置为 1 会为非特权用户的 JIT 编译做一些额外的加固工作。这些额外加固会稍微降低程序的性能，但在有非受信用户在系统上进行操作的情况下，能够有效地减小潜在的受攻击面。但与完全切换到解释器相比，这些性能损失还是比较小的。对于 x86_64 JIT 编译器，如果设置了 CONFIG_RETPOLINE，尾调用的间接跳转（ indirect jump）就会用 retpoline 实现。写作本文时，在大部分现代 Linux 发行版上这个配置都是打开的。

Constant Blinding

当前，启用加固会在 JIT 编译时盲化（blind）BPF 程序中用户提供的所有 32 位和 64 位常量，以防御 JIT spraying攻击，这些攻击会将原生操作码作为立即数注入到内核。这种攻击有效是因为：立即数驻留在可执行内核内存（executable kernel memory）中，因此某些内核 bug 可能会触发一个跳转动作，如果跳转到立即数的开始位置，就会把它们当做原生指令开始执行。

盲化 JIT 常量通过对真实指令进行随机化（randomizing the actual instruction）实现 。在这种方式中，通过对指令进行重写，将原来基于立即数的操作转换成基于寄存器的操作。指令重写将加载值的过程分解为两部分：

1. 加载一个盲化后的（blinded）立即数 rnd ^ imm 到寄存器
2. 将寄存器和 rnd 进行异或操作（xor）

这样原始的 imm 立即数就驻留在寄存器中，可以用于真实的操作了。这里介绍的只是加载操作的盲化过程，实际上所有的通用操作都被盲化了。下面是加固关闭的情况下，某个程序的 JIT 编译结果：

1
2
3
4
5
6
7
8
9
10
11
12
13

$ echo 0 > /proc/sys/net/core/bpf_jit_harden

  ffffffffa034f5e9 + <x>:
  [...]
  39:   mov    $0xa8909090,%eax
  3e:   mov    $0xa8909090,%eax
  43:   mov    $0xa8ff3148,%eax
  48:   mov    $0xa89081b4,%eax
  4d:   mov    $0xa8900bb0,%eax
  52:   mov    $0xa810e0c1,%eax
  57:   mov    $0xa8908eb4,%eax
  5c:   mov    $0xa89020b0,%eax
  [...]

加固打开之后，以上程序被某个非特权用户通过 BPF 加载的结果（这里已经进行了常量盲化）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$ echo 1 > /proc/sys/net/core/bpf_jit_harden

  ffffffffa034f1e5 + <x>:
  [...]
  39:   mov    $0xe1192563,%r10d
  3f:   xor    $0x4989b5f3,%r10d
  46:   mov    %r10d,%eax
  49:   mov    $0xb8296d93,%r10d
  4f:   xor    $0x10b9fd03,%r10d
  56:   mov    %r10d,%eax
  59:   mov    $0x8c381146,%r10d
  5f:   xor    $0x24c7200e,%r10d
  66:   mov    %r10d,%eax
  69:   mov    $0xeb2a830e,%r10d
  6f:   xor    $0x43ba02ba,%r10d
  76:   mov    %r10d,%eax
  79:   mov    $0xd9730af,%r10d
  7f:   xor    $0xa5073b1f,%r10d
  86:   mov    %r10d,%eax
  89:   mov    $0x9a45662b,%r10d
  8f:   xor    $0x325586ea,%r10d
  96:   mov    %r10d,%eax
  [...]

两个程序在语义上是一样的，但在第二种方式中，原来的立即数在反汇编之后的程序中不再可见。同时，加固还会禁止任何 JIT 内核符合（kallsyms）暴露给特权用户，JIT 镜像地址不再出现在 /proc/kallsyms 中。

Offloads

BPF 网络程序，尤其是 tc 和 XDP BPF 程序在内核中都有一个 offload 到硬件的接口，这样就可以直接在网卡上执行 BPF 程序。

当前，Netronome 公司的 nfp 驱动支持通过 JIT 编译器 offload BPF，它会将 BPF 指令翻译成网卡实现的指令集。另外，它还支持将 BPF maps offload 到网卡，因此 offloaded BPF 程序可以执行 map 查找、更新和删除操作。

eBPF 接口

BPF 系统调用

eBPF 提供了 bpf() 系统调用来对 BPF Map 或 程序进行操作，其函数原型如下：

1
2

#include <linux/bpf.h>
int bpf(int cmd, union bpf_attr *attr, unsigned int size);

函数有三个参数，其中：

• cmd 指定了 bpf 系统调用执行的命令类型，每个 cmd 都会附带一个参数 attr
• bpf_attr union 允许在内核和用户空间之间传递数据，确切的格式取决于 cmd 这个参数
• size 这个参数表示bpf_attr union 这个对象以字节为单位的大小

cmd 可以为一下几种类型，基本上可以分为操作 eBPF Map 和操作 eBPF 程序两种类型：

• BPF_MAP_CREATE：创建一个 eBPF Map 并且返回指向该 Map 的文件描述符
• BPF_MAP_LOOKUP_ELEM：在某个 Map 中根据 key 查找元素并返回其 value
• BPF_MAP_UPDATE_ELEM：在某个 Map 中创建或者更新一个元素 key/value 对
• BPF_MAP_DELETE_ELEM：在某个 Map 中根据 key 删除一个元素
• BPF_MAP_GET_NEXT_KEY：在某个 Map 中根据 key 查找元素然后返回下一个元素的 key
• BPF_PROG_LOAD：校验并加载 eBPF 程序，返回与该程序关联的文件描述符
• …

bpf_attr union 的结构如下所示，根据不同的 cmd 可以填充不同的信息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

union bpf_attr {
  struct {    /* Used by BPF_MAP_CREATE */
    __u32         map_type;
    __u32         key_size;    /* size of key in bytes */
    __u32         value_size;  /* size of value in bytes */
    __u32         max_entries; /* maximum number of entries in a map */
  };

  struct {    /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY commands */
    __u32         map_fd;
    __aligned_u64 key;
    union {
      __aligned_u64 value;
      __aligned_u64 next_key;
    };
    __u64         flags;
  };

  struct {    /* Used by BPF_PROG_LOAD */
    __u32         prog_type;
    __u32         insn_cnt;
    __aligned_u64 insns;      /* 'const struct bpf_insn *' */
    __aligned_u64 license;    /* 'const char *' */
    __u32         log_level;  /* verbosity level of verifier */
    __u32         log_size;   /* size of user buffer */
    __aligned_u64 log_buf;    /* user supplied 'char *' buffer */
    __u32         kern_version; /* checked when prog_type=kprobe (since Linux 4.1) */
  };
} __attribute__((aligned(8)));

使用 eBPF 程序的命令

BPF_PROG_LOAD 命令用于校验和加载 eBPF 程序，其需要填充的参数 bpf_xattr，下面展示了在 libbpf 中 bpf_load_program 的实现，可以看到最终是调用了 bpf 系统调用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
     size_t insns_cnt, const char *license,
     __u32 kern_version, char *log_buf,
     size_t log_buf_sz)
{
struct bpf_load_program_attr load_attr;

memset(&load_attr, 0, sizeof(struct bpf_load_program_attr));
load_attr.prog_type = type;
load_attr.expected_attach_type = 0;
load_attr.name = NULL;
load_attr.insns = insns;
load_attr.insns_cnt = insns_cnt;
load_attr.license = license;
load_attr.kern_version = kern_version;

return bpf_load_program_xattr(&load_attr, log_buf, log_buf_sz);
}

int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
   char *log_buf, size_t log_buf_sz)
{
  // ...
  fd = sys_bpf_prog_load(&attr, sizeof(attr));
if (fd >= 0)
return fd;
  // ...
}

static inline int sys_bpf_prog_load(union bpf_attr *attr, unsigned int size)
{
int fd;

do {
fd = sys_bpf(BPF_PROG_LOAD, attr, size);
} while (fd < 0 && errno == EAGAIN);

return fd;
}

使用 eBPF Map 的命令

和前面一样，查看 libbpf 中 bpf_create_map 的实现，可以看到最终也调用了 bpf 系统调用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37