20 容器安全（2）：在容器中，我不以root用户来运行程序可以吗？

你好，我是程远。

在上一讲里，我们学习了 Linux capabilities 的概念，也知道了对于非 privileged 的容器，容器中 root 用户的 capabilities 是有限制的，因此容器中的 root 用户无法像宿主机上的 root 用户一样，拿到完全掌控系统的特权。

那么是不是让非 privileged 的容器以 root 用户来运行程序，这样就能保证安全了呢？这一讲，我们就来聊一聊容器中的 root 用户与安全相关的问题。

问题再现

说到容器中的用户（user），你可能会想到，在 Linux Namespace 中有一项隔离技术，也就是 User Namespace。

不过在容器云平台 Kubernetes 上目前还不支持 User Namespace，所以我们先来看看在没有 User Namespace 的情况下，容器中用 root 用户运行，会发生什么情况。

首先，我们可以用下面的命令启动一个容器，在这里，我们把宿主机上 /etc 目录以 volume 的形式挂载到了容器中的 /mnt 目录下面。

1

# docker run -d --name root_example -v /etc:/mnt  centos sleep 3600

然后，我们可以看一下容器中的进程”sleep 3600”，它在容器中和宿主机上的用户都是 root，也就是说，容器中用户的 uid/gid 和宿主机上的完全一样。

1
2
3
4
5
6

# docker exec -it root_example bash -c "ps -ef | grep sleep"

root         1     0  0 01:14 ?        00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 3600
# ps -ef | grep sleep

root      5473  5443  0 18:14 ?        00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 3600

虽然容器里 root 用户的 capabilities 被限制了一些，但是在容器中，对于被挂载上来的 /etc 目录下的文件，比如说 shadow 文件，以这个 root 用户的权限还是可以做修改的。

1
2
3
4
5
6
7

# docker exec -it root_example bash

[[email protected] /]# ls /mnt/shadow -l

---------- 1 root root 586 Nov 26 13:47 /mnt/shadow

[[email protected] /]# echo "hello" >> /mnt/shadow

接着我们看看后面这段命令输出，可以确认在宿主机上文件被修改了。

1
2
3
4
5
6
7

# tail -n 3 /etc/shadow

grafana:!!:18437::::::

tcpdump:!!:18592::::::

hello

这个例子说明容器中的 root 用户也有权限修改宿主机上的关键文件。

当然在云平台上，比如说在 Kubernetes 里，我们是可以限制容器去挂载宿主机的目录的。

不过，由于容器和宿主机是共享 Linux 内核的，一旦软件有漏洞，那么容器中以 root 用户运行的进程就有机会去修改宿主机上的文件了。比如 2019 年发现的一个 RunC 的漏洞 CVE-2019-5736， 这导致容器中 root 用户有机会修改宿主机上的 RunC 程序，并且容器中的 root 用户还会得到宿主机上的运行权限。

问题分析

对于前面的问题，接下来我们就来讨论一下解决办法，在讨论问题的过程中，也会涉及一些新的概念，主要有三个。

方法一：Run as non-root user（给容器指定一个普通用户）

我们如果不想让容器以 root 用户运行，最直接的办法就是给容器指定一个普通用户 uid。这个方法很简单，比如可以在 docker 启动容器的时候加上”-u”参数，在参数中指定 uid/gid。

具体的操作代码如下：

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

# docker run -ti --name root_example -u 6667:6667 -v /etc:/mnt  centos bash

bash-4.4$ id

uid=6667 gid=6667 groups=6667

bash-4.4$ ps -ef

UID        PID  PPID  C STIME TTY          TIME CMD

6667         1     0  1 01:27 pts/0    00:00:00 bash

6667         8     1  0 01:27 pts/0    00:00:00 ps -ef

还有另外一个办法，就是我们在创建容器镜像的时候，用 Dockerfile 为容器镜像里建立一个用户。

为了方便你理解，我还是举例说明。就像下面例子中的 nonroot，它是一个用户名，我们用 USER 关键字来指定这个 nonroot 用户，这样操作以后，容器里缺省的进程都会以这个用户启动。

这样在运行 Docker 命令的时候就不用加”-u”参数来指定用户了。

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

# cat Dockerfile

FROM centos
RUN adduser -u 6667 nonroot

USER nonroot
# docker build -t registry/nonroot:v1 .

…
# docker run -d --name root_example -v /etc:/mnt registry/nonroot:v1 sleep 3600

050809a716ab0a9481a6dfe711b332f74800eff5fea8b4c483fa370b62b4b9b3
# docker exec -it root_example bash

[[email protected] /]$ id

uid=6667(nonroot) gid=6667(nonroot) groups=6667(nonroot)

[[email protected] /]$ ps -ef

UID        PID  PPID  C STIME TTY          TIME CMD

nonroot      1     0  0 01:43 ?        00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 3600

好，在容器中使用普通用户运行之后，我们再看看，现在能否修改被挂载上来的 /etc 目录下的文件? 显然，现在不可以修改了。

1
2
3

[[email protected] /]$ echo "hello" >> /mnt/shadow

bash: /mnt/shadow: Permission denied

那么是不是只要给容器中指定了一个普通用户，这个问题就圆满解决了呢？其实在云平台上，这么做还是会带来别的问题，我们一起来看看。

由于用户 uid 是整个节点中共享的，那么在容器中定义的 uid，也就是宿主机上的 uid，这样就很容易引起 uid 的冲突。

比如说，多个客户在建立自己的容器镜像的时候都选择了同一个 uid 6667。那么当多个客户的容器在同一个节点上运行的时候，其实就都使用了宿主机上 uid 6667。

我们都知道，在一台 Linux 系统上，每个用户下的资源是有限制的，比如打开文件数目（open files）、最大进程数目（max user processes）等等。一旦有很多个容器共享一个 uid，这些容器就很可能很快消耗掉这个 uid 下的资源，这样很容易导致这些容器都不能再正常工作。

要解决这个问题，必须要有一个云平台级别的 uid 管理和分配，但选择这个方法也要付出代价。因为这样做是可以解决问题，但是用户在定义自己容器中的 uid 的时候，他们就需要有额外的操作，而且平台也需要新开发对 uid 平台级别的管理模块，完成这些事情需要的工作量也不少。

方法二：User Namespace（用户隔离技术的支持）

那么在没有使用 User Namespace 的情况，对于容器平台上的用户管理还是存在问题。你可能会想到，我们是不是应该去尝试一下 User Namespace?

好的，我们就一起来看看使用 User Namespace 对解决用户管理问题有没有帮助。首先，我们简单了解一下User Namespace的概念。

User Namespace 隔离了一台 Linux 节点上的 User ID（uid）和 Group ID（gid），它给 Namespace 中的 uid/gid 的值与宿主机上的 uid/gid 值建立了一个映射关系。经过 User Namespace 的隔离，我们在 Namespace 中看到的进程的 uid/gid，就和宿主机 Namespace 中看到的 uid 和 gid 不一样了。

你可以看下面的这张示意图，应该就能很快知道 User Namespace 大概是什么意思了。比如 namespace_1 里的 uid 值是 0 到 999，但其实它在宿主机上对应的 uid 值是 1000 到 1999。

还有一点你要注意的是，User Namespace 是可以嵌套的，比如下面图里的 namespace_2 里可以再建立一个 namespace_3，这个嵌套的特性是其他 Namespace 没有的。

我们可以启动一个带 User Namespace 的容器来感受一下。这次启动容器，我们用一下podman这个工具，而不是 Docker。

跟 Docker 相比，podman 不再有守护进程 dockerd，而是直接通过 fork/execve 的方式来启动一个新的容器。这种方式启动容器更加简单，也更容易维护。

Podman 的命令参数兼容了绝大部分的 docker 命令行参数，用过 Docker 的同学也很容易上手 podman。你感兴趣的话，可以跟着这个手册在你自己的 Linux 系统上装一下 podman。

那接下来，我们就用下面的命令来启动一个容器：

1

# podman run -ti  -v /etc:/mnt --uidmap 0:2000:1000 centos bash

我们可以看到，其他参数和前面的 Docker 命令是一样的。

这里我们在命令里增加一个参数，”–uidmap 0:2000:1000”，这个是标准的 User Namespace 中 uid 的映射格式：”ns_uid:host_uid:amount”。

那这个例子里的”0:2000:1000”是什么意思呢？我给你解释一下。

第一个 0 是指在新的 Namespace 里 uid 从 0 开始，中间的那个 2000 指的是 Host Namespace 里被映射的 uid 从 2000 开始，最后一个 1000 是指总共需要连续映射 1000 个 uid。

所以，我们可以得出，这个容器里的 uid 0 是被映射到宿主机上的 uid 2000 的。这一点我们可以验证一下。

首先，我们先在容器中以用户 uid 0 运行一下 sleep 这个命令：

1
2
3
4
5

# id

uid=0(root) gid=0(root) groups=0(root)

# sleep 3600

然后就是第二步，到宿主机上查看一下这个进程的 uid。这里我们可以看到，进程 uid 的确是 2000 了。

1
2
3

# ps -ef |grep sleep

2000     27021 26957  0 01:32 pts/0    00:00:00 /usr/bin/coreutils --coreutils-prog-shebang=sleep /usr/bin/sleep 3600

第三步，我们可以再回到容器中，仍然以容器中的 root 对被挂载上来的 /etc 目录下的文件做操作，这时可以看到操作是不被允许的。

1
2
3
4
5
6
7

# echo "hello" >> /mnt/shadow

bash: /mnt/shadow: Permission denied

# id

uid=0(root) gid=0(root) groups=0(root)

好了，通过这些操作以及和前面 User Namespace 的概念的解释，我们可以总结出容器使用 User Namespace 有两个好处。

第一，它把容器中 root 用户（uid 0）映射成宿主机上的普通用户。

作为容器中的 root，它还是可以有一些 Linux capabilities，那么在容器中还是可以执行一些特权的操作。而在宿主机上 uid 是普通用户，那么即使这个用户逃逸出容器 Namespace，它的执行权限还是有限的。

第二，对于用户在容器中自己定义普通用户 uid 的情况，我们只要为每个容器在节点上分配一个 uid 范围，就不会出现在宿主机上 uid 冲突的问题了。

因为在这个时候，我们只要在节点上分配容器的 uid 范围就可以了，所以从实现上说，相比在整个平台层面给容器分配 uid，使用 User Namespace 这个办法要方便得多。

这里我额外补充一下，前面我们说了 Kubernetes 目前还不支持 User Namespace，如果你想了解相关工作的进展，可以看一下社区的这个PR。

方法三：rootless container（以非 root 用户启动和管理容器）

前面我们已经讨论了，在容器中以非 root 用户运行进程可以降低容器的安全风险。除了在容器中使用非 root 用户，社区还有一个 rootless container 的概念。

这里 rootless container 中的”rootless”不仅仅指容器中以非 root 用户来运行进程，还指以非 root 用户来创建容器，管理容器。也就是说，启动容器的时候，Docker 或者 podman 是以非 root 用户来执行的。

这样一来，就能进一步提升容器中的安全性，我们不用再担心因为 containerd 或者 RunC 里的代码漏洞，导致容器获得宿主机上的权限。

我们可以参考 redhat blog 里的这篇文档， 在宿主机上用 redhat 这个用户通过 podman 来启动一个容器。在这个容器中也使用了 User Namespace，并且把容器中的 uid 0 映射为宿主机上的 redhat 用户了。

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

$ id

uid=1001(redhat) gid=1001(redhat) groups=1001(redhat)

$ podman run -it  ubi7/ubi bash   ### 在宿主机上以redhat用户启动容器

[[email protected] /]# id     ### 容器中的用户是root

uid=0(root) gid=0(root) groups=0(root)

[[email protected] /]# sleep 3600   ### 在容器中启动一个sleep 进程
# ps -ef |grep sleep   ###在宿主机上查看容器sleep进程对应的用户

redhat   29433 29410  0 05:14 pts/0    00:00:00 sleep 3600

目前 Docker 和 podman 都支持了 rootless container，Kubernetes 对rootless container 支持的工作也在进行中。

重点小结

我们今天讨论的内容是 root 用户与容器安全的问题。

尽管容器中 root 用户的 Linux capabilities 已经减少了很多，但是在没有 User Namespace 的情况下，容器中 root 用户和宿主机上的 root 用户的 uid 是完全相同的，一旦有软件的漏洞，容器中的 root 用户就可以操控整个宿主机。

为了减少安全风险，业界都是建议在容器中以非 root 用户来运行进程。不过在没有 User Namespace 的情况下，在容器中使用非 root 用户，对于容器云平台来说，对 uid 的管理会比较麻烦。

所以，我们还是要分析一下 User Namespace，它带来的好处有两个。一个是把容器中 root 用户（uid 0）映射成宿主机上的普通用户，另外一个好处是在云平台里对于容器 uid 的分配要容易些。

除了在容器中以非 root 用户来运行进程外，Docker 和 podman 都支持了 rootless container，也就是说它们都可以以非 root 用户来启动和管理容器，这样就进一步降低了容器的安全风险。

思考题

我在这一讲里提到了 rootless container，不过对于 rootless container 的支持，还存在着不少的难点，比如容器网络的配置、Cgroup 的配置，你可以去查阅一些资料，看看 podman 是怎么解决这些问题的。

欢迎你在留言区提出你的思考和疑问。如果这一讲对你有帮助，也欢迎转发给你的同事、朋友，一起交流学习。

加餐06 BCC：入门eBPF的前端工具

你好，我是程远。

今天是我们专题加餐的最后一讲，明天就是春节了，我想给还在学习的你点个赞。这里我先给你拜个早年，祝愿你牛年工作顺利，健康如意！

上一讲，我们学习了 eBPF 的基本概念，以及 eBPF 编程的一个基本模型。在理解了这些概念之后，从理论上来说，你就能自己写出 eBPF 的程序，对 Linux 系统上的一些问题做跟踪和调试了。

不过，从上一讲的例子里估计你也发现了，eBPF 的程序从编译到运行还是有些复杂。

为了方便我们用 eBPF 的程序跟踪和调试系统，社区有很多 eBPF 的前端工具。在这些前端工具中，BCC 提供了最完整的工具集，以及用于 eBPF 工具开发的 Python/Lua/C++ 的接口。那么今天我们就一起来看看，怎么使用 BCC 这个 eBPF 的前端工具。

如何使用 BCC 工具

BCC（BPF Compiler Collection）这个社区项目开始于 2015 年，差不多在内核中支持了 eBPF 的特性之后，BCC 这个项目就开始了。

BCC 的目标就是提供一个工具链，用于编写、编译还有内核加载 eBPF 程序，同时 BCC 也提供了大量的 eBPF 的工具程序，这些程序能够帮我们做 Linux 的性能分析和跟踪调试。

这里我们可以先尝试用几个 BCC 的工具，通过实际操作来了解一下 BCC。

大部分 Linux 发行版本都有 BCC 的软件包，你可以直接安装。比如我们可以在 Ubuntu 20.04 上试试，用下面的命令安装 BCC：

1
2
3
4

# apt install bpfcc-tools

``
安装完 BCC 软件包之后，你在 Linux 系统上就会看到多了 100 多个 BCC 的小工具 （在 Ubuntu 里，这些工具的名字后面都加了 bpfcc 的后缀）：

ls -l /sbin/*-bpfcc | more

-rwxr-xr-x 1 root root 34536 Feb 7 2020 /sbin/argdist-bpfcc -rwxr-xr-x 1 root root 2397 Feb 7 2020 /sbin/bashreadline-bpfcc -rwxr-xr-x 1 root root 6231 Feb 7 2020 /sbin/biolatency-bpfcc -rwxr-xr-x 1 root root 5524 Feb 7 2020 /sbin/biosnoop-bpfcc -rwxr-xr-x 1 root root 6439 Feb 7 2020 /sbin/biotop-bpfcc -rwxr-xr-x 1 root root 1152 Feb 7 2020 /sbin/bitesize-bpfcc -rwxr-xr-x 1 root root 2453 Feb 7 2020 /sbin/bpflist-bpfcc -rwxr-xr-x 1 root root 6339 Feb 7 2020 /sbin/btrfsdist-bpfcc -rwxr-xr-x 1 root root 9973 Feb 7 2020 /sbin/btrfsslower-bpfcc -rwxr-xr-x 1 root root 4717 Feb 7 2020 /sbin/cachestat-bpfcc -rwxr-xr-x 1 root root 7302 Feb 7 2020 /sbin/cachetop-bpfcc -rwxr-xr-x 1 root root 6859 Feb 7 2020 /sbin/capable-bpfcc -rwxr-xr-x 1 root root 53 Feb 7 2020 /sbin/cobjnew-bpfcc -rwxr-xr-x 1 root root 5209 Feb 7 2020 /sbin/cpudist-bpfcc -rwxr-xr-x 1 root root 14597 Feb 7 2020 /sbin/cpuunclaimed-bpfcc -rwxr-xr-x 1 root root 8504 Feb 7 2020 /sbin/criticalstat-bpfcc -rwxr-xr-x 1 root root 7095 Feb 7 2020 /sbin/dbslower-bpfcc -rwxr-xr-x 1 root root 3780 Feb 7 2020 /sbin/dbstat-bpfcc -rwxr-xr-x 1 root root 3938 Feb 7 2020 /sbin/dcsnoop-bpfcc -rwxr-xr-x 1 root root 3920 Feb 7 2020 /sbin/dcstat-bpfcc -rwxr-xr-x 1 root root 19930 Feb 7 2020 /sbin/deadlock-bpfcc -rwxr-xr-x 1 root root 7051 Dec 10 2019 /sbin/deadlock.c-bpfcc -rwxr-xr-x 1 root root 6830 Feb 7 2020 /sbin/drsnoop-bpfcc -rwxr-xr-x 1 root root 7658 Feb 7 2020 /sbin/execsnoop-bpfcc -rwxr-xr-x 1 root root 10351 Feb 7 2020 /sbin/exitsnoop-bpfcc -rwxr-xr-x 1 root root 6482 Feb 7 2020 /sbin/ext4dist-bpfcc …

1
2
3
4
5
6
7
8

这些工具几乎覆盖了 Linux 内核中各个模块，它们可以对 Linux 某个模块做最基本的 profile。你可以看看下面这张图，图里把 BCC 的工具与 Linux 中的各个模块做了一个映射。
![img](assets/eb90017c78byyyy5399d275fe63783db.png)
在 BCC 的 github repo 里，也有很完整的文档和例子来描述每一个工具。Brendan D. Gregg写了一本书，书名叫《BPF Performance Tools》（我们上一讲也提到过这本书），这本书从 Linux CPU/Memory/Filesystem/Disk/Networking 等角度介绍了如何使用 BCC 工具，感兴趣的你可以自行学习。
为了让你更容易理解，这里我给你举两个例子。
第一个是使用 opensnoop 工具，用它来监控节点上所有打开文件的操作。这个命令有时候也可以用来查看某个文件被哪个进程给动过。
比如说，我们先启动 opensnoop，然后在其他的 console 里运行 touch test-open 命令，这时候我们就会看到 touch 命令在启动时读取到的库文件和配置文件，以及最后建立的“test-open”这个文件。

opensnoop-bpfcc

PID COMM FD ERR PATH 2522843 touch 3 0 /etc/ld.so.cache 2522843 touch 3 0 /lib/x86_64-linux-gnu/libc.so.6 2522843 touch 3 0 /usr/lib/locale/locale-archive 2522843 touch 3 0 /usr/share/locale/locale.alias 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_IDENTIFICATION 2522843 touch 3 0 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_MEASUREMENT 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_TELEPHONE 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_ADDRESS 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_NAME 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_PAPER 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_MESSAGES 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_MESSAGES/SYS_LC_MESSAGES 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_MONETARY 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_COLLATE 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_TIME 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_NUMERIC 2522843 touch 3 0 /usr/lib/locale/C.UTF-8/LC_CTYPE 2522843 touch 3 0 test-open

1
2
3
4
5

第二个是使用 softirqs 这个命令，查看节点上各种类型的 softirqs 花费时间的分布图 （直方图模式）。
比如在下面这个例子里，每一次 timer softirq 执行时间在 0～1us 时间区间里的有 16 次，在 2-3us 时间区间里的有 49 次，以此类推。
在我们分析网络延时的时候，也用过这个 softirqs 工具，用它来确认 timer softirq 花费的时间。

softirqs-bpfcc -d

Tracing soft irq event time… Hit Ctrl-C to end. ^C

softirq = block usecs : count distribution 0 -> 1 : 2 |******************** | 2 -> 3 : 3 |****************************** | 4 -> 7 : 2 |******************** | 8 -> 15 : 4 |****************************************|

softirq = rcu usecs : count distribution 0 -> 1 : 189 |***********************************| 2 -> 3 : 52 |*********** | 4 -> 7 : 21 | | 8 -> 15 : 5 | | 16 -> 31 : 1 | |

softirq = net_rx usecs : count distribution 0 -> 1 : 1 |******************** | 2 -> 3 : 0 | | 4 -> 7 : 2 || 8 -> 15 : 0 | | 16 -> 31 : 2 ||

softirq = timer usecs : count distribution 0 -> 1 : 16 |************* | 2 -> 3 : 49 |****************| 4 -> 7 : 43 |*********************************** | 8 -> 15 : 5 | | 16 -> 31 : 13 | | 32 -> 63 : 13 | |

softirq = sched usecs : count distribution 0 -> 1 : 18 |****** | 2 -> 3 : 107 |*********************************| 4 -> 7 : 20 | | 8 -> 15 : 1 | | 16 -> 31 : 1 | |

1
2
3
4
5
6
7
8
9
10

BCC 中的工具数目虽然很多，但是你用过之后就会发现，它们的输出模式基本上就是上面我说的这两种。
第一种类似事件模式，就像 opensnoop 的输出一样，发生一次就输出一次；第二种是直方图模式，就是把内核中执行函数的时间做个统计，然后用直方图的方式输出，也就是 softirqs -d 的执行结果。
用过 BCC 工具之后，我们再来看一下 BCC 工具的工作原理，这样以后你有需要的时候，自己也可以编写和部署一个 BCC 工具了。
## BCC 的工作原理
让我们来先看一下 BCC 工具的代码结构。
因为目前 BCC 的工具都是用 python 写的，所以你直接可以用文本编辑器打开节点上的一个工具文件。比如打开 /sbin/opensnoop-bpfcc 文件（也可在 github bcc 项目中查看 opensnoop.py），这里你可以看到大概 200 行左右的代码，代码主要分成了两部分。
第一部分其实是一块 C 代码，里面定义的就是 eBPF 内核态的代码，不过它是以 python 字符串的形式加在代码中的。
我在下面列出了这段 C 程序的主干，其实就是定义两个 eBPF Maps 和两个 eBPF Programs 的函数：

define BPF program

bpf_text = “”” #include <uapi/linux/ptrace.h> #include <uapi/linux/limits.h> #include <linux/sched.h>

…

BPF_HASH(infotmp, u64, struct val_t); //BPF_MAP_TYPE_HASH BPF_PERF_OUTPUT(events); // BPF_MAP_TYPE_PERF_EVENT_ARRAY

int trace_entry(struct pt_regs *ctx, int dfd, const char __user *filename, int flags) { … }

int trace_return(struct pt_regs *ctx) { … } “””

1
2
3

第二部分就是用 python 写的用户态代码，它的作用是加载内核态 eBPF 的代码，把内核态的函数 trace_entry() 以 kprobe 方式挂载到内核函数 do_sys_open()，把 trace_return() 以 kproberet 方式也挂载到 do_sys_open()，然后从 eBPF Maps 里读取数据并且输出。

…

initialize BPF

b = BPF(text=bpf_text) b.attach_kprobe(event=”do_sys_open”, fn_name=”trace_entry”) b.attach_kretprobe(event=”do_sys_open”, fn_name=”trace_return”) …

loop with callback to print_event

b[“events”].open_perf_buffer(print_event, page_cnt=64) start_time = datetime.now() while not args.duration or datetime.now() - start_time < args.duration: try: b.perf_buffer_poll() except KeyboardInterrupt: exit() …

1
2
3
4

从代码的结构看，其实这和我们上一讲介绍的 eBPF 标准的编程模式是差不多的，只是用户态的程序是用 python 来写的。不过这里有一点比较特殊，用户态在加载程序的时候，输入的是 C 程序的文本而不是 eBPF bytecode。
BCC 可以这么做，是因为它通过 pythonBPF()  加载 C 代码之后，调用 libbcc 库中的函数 bpf_module_create_c_from_string() 把 C 代码编译成了 eBPF bytecode。也就是说，libbcc 库中集成了 clang/llvm 的编译器。

1
2
3
4
5

def __init__(self, src_file=b"", hdr_file=b"", text=None, debug=0,

        cflags=[], usdt_contexts=[], allow_rlimit=True, device=None):

    """Create a new BPF module with the given source code.

… self.module = lib.bpf_module_create_c_from_string(text, self.debug，cflags_array, len(cflags_array), allow_rlimit, device) …

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

我们弄明白 libbcc 库的作用之后，再来整体看一下 BCC 工具的工作方式。为了让你理解，我给你画了一张示意图：
![img](assets/94b146c3f35ca0b9aa04c32f29fdf572.jpeg)
BCC 的这种设计思想是为了方便 eBPF 程序的开发和使用，特别是 eBPF 内核态的代码对当前运行的内核版本是有依赖的，比如在 4.15 内核的节点上编译好的 bytecode，放到 5.4 内核的节点上很有可能是运行不了的。
那么让编译和运行都在同一个节点，出现问题就可以直接修改源代码文件了。你有没有发现，这么做有点像把 C 程序的处理当成 python 的处理方式。
BCC 的这种设计思想虽然有好处，但是也带来了问题。其实问题也是很明显的，首先我们需要在运行 BCC 工具的节点上必须安装内核头文件，这个在编译内核态 eBPF C 代码的时候是必须要做的。
其次，在 libbcc 的库里面包含了 clang/llvm 的编译器，这不光占用磁盘空间，在运行程序前还需要编译，也会占用节点的 CPU 和 Memory，同时也让 BCC 工具的启动时间变长。这两个问题都会影响到 BCC 生产环境中的使用。
## BCC 工具的发展
那么我们有什么办法来解决刚才说的问题呢？eBPF 的技术在不断进步，最新的 BPF CO-RE 技术可以解决这个问题。我们下面就来看 BPF CO-RE 是什么意思。
CO-RE 是“Compile Once – Run Everywhere”的缩写，BPF CO-RE 通过对 Linux 内核、用户态 BPF loader（libbpf 库）以及 Clang 编译器的修改，来实现编译出来的 eBPF 程序可以在不同版本的内核上运行。
不同版本的内核上，用 CO-RE 编译出来的 eBPF 程序都可以运行。在 Linux 内核和 BPF 程序之间，会通过BTF（BPF Type Format）来协调不同版本内核中数据结构的变量偏移或者变量长度变化等问题。
在 BCC 的 github repo 里，有一个目录libbpf-tools，在这个目录下已经有一些重写过的 BCC 工具的源代码，它们并不是用 python+libbcc 的方式实现的，而是用到了 libbpf+BPF CO-RE 的方式。
如果你的系统上有高于版本 10 的 CLANG/LLVM 编译器，就可以尝试编译一下 libbpf-tools 下的工具。这里可以加一个“V=1”参数，这样我们就能清楚编译的步骤了。

git remote -v

origin https://github.com/iovisor/bcc.git (fetch) origin https://github.com/iovisor/bcc.git (push)

cd libbpf-tools/

make V=1

mkdir -p .output mkdir -p .output/libbpf make -C /root/bcc/src/cc/libbpf/src BUILD_STATIC_ONLY=1
OBJDIR=/root/bcc/libbpf-tools/.output//libbpf DESTDIR=/root/bcc/libbpf-tools/.output/
INCLUDEDIR= LIBDIR= UAPIDIR=
Install …

ar rcs /root/bcc/libbpf-tools/.output//libbpf/libbpf.a …

…

clang -g -O2 -target bpf -D__TARGET_ARCH_x86
-I.output -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 -c opensnoop.c -o .output/opensnoop.o cc -g -O2 -Wall .output/opensnoop.o /root/bcc/libbpf-tools/.output/libbpf.a .output/trace_helpers.o .output/syscall_helpers.o .output/errno_helpers.o -lelf -lz -o opensnoop

…

1
2
3
4
5

我们梳理一下编译的过程。首先这段代码生成了 libbpf.a 这个静态库，然后逐个的编译每一个工具。对于每一个工具的代码结构是差不多的，编译的方法也是差不多的。
我们拿 opensnoop 做例子来看一下，它的源代码分为两个文件。opensnoop.bpf.c 是内核态的 eBPF 代码，opensnoop.c 是用户态的代码，这个和我们之前学习的 eBPF 代码的标准结构是一样的。主要不同点有下面这些。
内核态的代码不再逐个 include 内核代码的头文件，而是只要 include 一个“vmlinux.h”就可以。在“vmlinux.h”中包含了所有内核的数据结构，它是由内核文件 vmlinux 中的 BTF 信息转化而来的。

cat opensnoop.bpf.c | head

// SPDX-License-Identifier: GPL-2.0 // Copyright (c) 2019 Facebook // Copyright (c) 2020 Netflix #include “vmlinux.h” #include <bpf/bpf_helpers.h> #include “opensnoop.h”

#define TASK_RUNNING 0

const volatile __u64 min_us = 0;

1
2
3

我们使用bpftool这个工具，可以把编译出来的 opensnoop.bpf.o 重新生成为一个 C 语言的头文件 opensnoop.skel.h。这个头文件中定义了加载 eBPF 程序的函数，eBPF bytecode 的二进制流也直接写在了这个头文件中。

bin/bpftool gen skeleton .output/opensnoop.bpf.o > .output/opensnoop.skel.h

1
2
3
4

用户态的代码 opensnoop.c 直接 include 这个 opensnoop.skel.h，并且调用里面的 eBPF 加载的函数。这样在编译出来的可执行程序 opensnoop，就可以直接运行了，不用再找 eBPF bytecode 文件或者 eBPF 内核态的 C 文件。并且这个 opensnoop 程序可以运行在不同版本内核的节点上（当然，这个内核需要打开 CONFIG_DEBUG_INFO_BTF 这个编译选项）。
比如，我们可以把在 kernel5.4 节点上编译好的 opensnoop 程序 copy 到一台 kernel5.10.4 的节点来运行：

uname -r

5.10.4

ls -lh opensnoop

-rwxr-x— 1 root root 235K Jan 30 23:08 opensnoop

./opensnoop

PID COMM FD ERR PATH 2637411 opensnoop 24 0 /etc/localtime 1 systemd 28 0 /proc/746/cgroup

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

从上面的代码我们会发现，这时候的 opensnoop 不依赖任何的库函数，只有一个文件，strip 后的文件大小只有 235KB，启动运行的时候，既不不需要读取外部的文件，也不会做额外的编译。
## 重点小结
好了，今天我们主要讲了 eBPF 的一个前端工具 BCC，我来给你总结一下。
在我看来，对于把 eBPF 运用于 Linux 内核的性能分析和跟踪调试这个领域，BCC 是社区中最有影响力的一个项目。BCC 项目提供了 eBPF 工具开发的 Python/Lua/C++ 的接口，以及上百个基于 eBPF 的工具。
对不熟悉 eBPF 的同学来说，可以直接拿这些工具来调试 Linux 系统中的问题。而对于了解 eBPF 的同学，也可以利用 BCC 提供的接口，开发自己需要的 eBPF 工具。
BCC 工具目前主要通过 ptyhon+libbcc 的模式在目标节点上运行，但是这个模式需要节点有内核头文件以及内嵌在 libbcc 中的 Clang/LLVM 编译器，每次程序启动的时候还需要再做一次编译。
为了弥补这个缺点，BCC 工具开始向 libbpf+BPF CO-RE 的模式转变。用这种新模式编译出来的 BCC 工具程序，只需要很少的系统资源就可以在目标节点上运行，并且不受内核版本的限制。
除了 BCC 之外，你还可以看一下bpftrace、ebpf-exporter等 eBPF 的前端工具。
bpftrace 提供了类似 awk 和 C 语言混合的一种语言，在使用时也很类似 awk，可以用一两行的命令来完成一次 eBPF 的调用，它能做一些简单的内核事件的跟踪。当然它也可以编写比较复杂的 eBPF 程序。
ebpf-exporter 可以把 eBPF 程序收集到的 metrics 以Prometheus的格式对外输出，然后通过Grafana的 dashboard，可以对内核事件做长期的以及更加直观的监控。
总之，前面提到的这些工具，你都可以好好研究一下，它们可以帮助你对容器云平台上的节点做内核级别的监控与诊断。
## 思考题
这一讲的最后，我给你留一道思考题吧。
你可以动手操作一下，尝试编译和运行 BCC 项目中libbpf-tools目录下的工具。
欢迎你在留言区记录你的心得或者疑问。如果这一讲对你有帮助，也欢迎分享给你的同事、朋友，和他一起学习进步。

加餐04 理解ftrace（2）：怎么理解ftrace背后的技术tracepoint和kprobe？

你好，我是程远。

前面两讲，我们分别学习了 perf 和 ftrace 这两个最重要 Linux tracing 工具。在学习过程中，我们把重点放在了这两个工具最基本的功能点上。

不过你学习完这些之后，我们内核调试版图的知识点还没有全部点亮。

如果你再去查看一些 perf、ftrace 或者其他 Linux tracing 相关资料，你可能会常常看到两个单词，“tracepoint”和“kprobe”。你有没有好奇过，这两个名词到底是什么意思，它们和 perf、ftrace 这些工具又是什么关系呢？

这一讲，我们就来学习这两个在 Linux tracing 系统中非常重要的概念，它们就是 tracepoint 和 kprobe。

tracepoint 和 kprobe 的应用举例

如果你深入地去看一些 perf 或者 ftrace 的功能，这时候你会发现它们都有跟 tracepoint、kprobe 相关的命令。我们先来看几个例子，通过这几个例子，你可以大概先了解一下 tracepoint 和 kprobe 的应用，这样我们后面做详细的原理介绍时，你也会更容易理解。

首先看看 tracepoint，tracepoint 其实就是在 Linux 内核的一些关键函数中埋下的 hook 点，这样在 tracing 的时候，我们就可以在这些固定的点上挂载调试的函数，然后查看内核的信息。

我们通过下面的这个 perf list 命令，就可以看到所有的 tracepoints：

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

# perf list | grep Tracepoint

  alarmtimer:alarmtimer_cancel                       [Tracepoint event]

  alarmtimer:alarmtimer_fired                        [Tracepoint event]

  alarmtimer:alarmtimer_start                        [Tracepoint event]

  alarmtimer:alarmtimer_suspend                      [Tracepoint event]

  block:block_bio_backmerge                          [Tracepoint event]

  block:block_bio_bounce                             [Tracepoint event]

  block:block_bio_complete                           [Tracepoint event]

  block:block_bio_frontmerge                         [Tracepoint event]

  block:block_bio_queue                              [Tracepoint event]

…

至于 ftrace，你在 tracefs 文件系统中，也会看到一样的 tracepoints：

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

# find /sys/kernel/debug/tracing/events -type d | sort

/sys/kernel/debug/tracing/events

/sys/kernel/debug/tracing/events/alarmtimer

/sys/kernel/debug/tracing/events/alarmtimer/alarmtimer_cancel

/sys/kernel/debug/tracing/events/alarmtimer/alarmtimer_fired

/sys/kernel/debug/tracing/events/alarmtimer/alarmtimer_start

/sys/kernel/debug/tracing/events/alarmtimer/alarmtimer_suspend

/sys/kernel/debug/tracing/events/block

/sys/kernel/debug/tracing/events/block/block_bio_backmerge

/sys/kernel/debug/tracing/events/block/block_bio_bounce

/sys/kernel/debug/tracing/events/block/block_bio_complete

/sys/kernel/debug/tracing/events/block/block_bio_frontmerge

…

为了让你更好理解，我们就拿“do_sys_open”这个 tracepoint 做例子。在内核函数 do_sys_open() 中，有一个 trace_do_sys_open() 调用，其实它这就是一个 tracepoint：

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

long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)

{

        struct open_flags op;

        int fd = build_open_flags(flags, mode, &op);

        struct filename *tmp;
        if (fd)

                return fd;
        tmp = getname(filename);

        if (IS_ERR(tmp))

                return PTR_ERR(tmp);
        fd = get_unused_fd_flags(flags);

        if (fd >= 0) {

                struct file *f = do_filp_open(dfd, tmp, &op);

                if (IS_ERR(f)) {

                        put_unused_fd(fd);

                        fd = PTR_ERR(f);

                } else {

                        fsnotify_open(f);

                        fd_install(fd, f);

                        trace_do_sys_open(tmp->name, flags, mode);

                }

        }

        putname(tmp);

        return fd;

}

接下来，我们可以通过 perf 命令，利用 tracepoint 来查看一些内核函数发生的频率，比如在节点上，统计 10 秒钟内调用 do_sys_open 成功的次数，也就是打开文件的次数。

1
2
3
4

# # perf stat -a -e fs:do_sys_open -- sleep 10
 Performance counter stats for 'system wide':
                 7      fs:do_sys_open
      10.001954100 seconds time elapsed

同时，如果我们把 tracefs 中 do_sys_open 的 tracepoint 打开，那么在 ftrace 的 trace 输出里，就可以看到具体 do_sys_open 每次调用成功时，打开的文件名、文件属性、对应的进程等信息。

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

# pwd

/sys/kernel/debug/tracing

# echo 1 > events/fs/do_sys_open/enable
# cat trace

# tracer: nop

#

#                              _-----=> irqs-off

#                             / _----=> need-resched

#                            | / _---=> hardirq/softirq

#                            || / _--=> preempt-depth

#                            ||| /     delay

#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION

#              | |       |   ||||       |         |

         systemd-1     [011] .... 17133447.451839: do_sys_open: "/proc/22597/cgroup" 88000 666

            bash-4118  [009] .... 17133450.076026: do_sys_open: "/" 98800 0

     salt-minion-7101  [010] .... 17133450.478659: do_sys_open: "/etc/hosts" 88000 666

 systemd-journal-2199  [011] .... 17133450.487930: do_sys_open: "/proc/6989/cgroup" 88000 666

 systemd-journal-2199  [011] .... 17133450.488019: do_sys_open: "/var/log/journal/d4f76e4bf5414ac78e1c534ebe5d0a72" 98800 0

 systemd-journal-2199  [011] .... 17133450.488080: do_sys_open: "/proc/6989/comm" 88000 666

 systemd-journal-2199  [011] .... 17133450.488114: do_sys_open: "/proc/6989/cmdline" 88000 666

 systemd-journal-2199  [011] .... 17133450.488143: do_sys_open: "/proc/6989/status" 88000 666

 systemd-journal-2199  [011] .... 17133450.488185: do_sys_open: "/proc/6989/sessionid" 88000 666

…

请注意，Tracepoint 是在内核中固定的 hook 点，并不是在所有的函数中都有 tracepoint。

比如在上面的例子里，我们看到 do_sys_open() 调用到了 do_filp_open()，但是 do_filp_open() 函数里是没有 tracepoint 的。那如果想看到 do_filp_open() 函数被调用的频率，或者 do_filp_open() 在被调用时传入参数的情况，我们又该怎么办呢？

这时候，我们就需要用到 kprobe 了。kprobe 可以动态地在所有的内核函数（除了 inline 函数）上挂载 probe 函数。我们还是结合例子做理解，先看看 perf 和 ftraces 是怎么利用 kprobe 来做调试的。

比如对于 do_filp_open() 函数，我们可以通过perf probe添加一下，然后用perf stat 看看在 10 秒钟的时间里，这个函数被调用到的次数。

1
2
3
4
5
6
7

# perf probe --add do_filp_open

# perf stat -a -e probe:do_filp_open -- sleep 10

 Performance counter stats for 'system wide':
                11      probe:do_filp_open
      10.001489223 seconds time elapsed

我们也可以通过 ftrace 的 tracefs 给 do_filp_open() 添加一个 kprobe event，这样就能查看 do_filp_open() 每次被调用的时候，前面两个参数的值了。

这里我要给你说明一下，在写入 kprobe_event 的时候，对于参数的定义我们用到了“%di”和“%si”。这是 x86 处理器里的寄存器，根据 x86 的Application Binary Interface 的文档，在函数被调用的时候，%di 存放了第一个参数，%si 存放的是第二个参数。

1

# echo 'p:kprobes/myprobe do_filp_open dfd=+0(%di):u32 pathname=+0(+0(%si)):string' > /sys/kernel/debug/tracing/kprobe_event

完成上面的写入之后，我们再 enable 这个新建的 kprobe event。这样在 trace 中，我们就可以看到每次 do_filp_open（）被调用时前两个参数的值了。

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

# echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable
# cat /sys/kernel/debug/tracing/trace

…

      irqbalance-1328  [005] .... 2773211.189573: myprobe: (do_filp_open+0x0/0x100) dfd=4294967295 pathname="/proc/interrupts"

      irqbalance-1328  [005] .... 2773211.189740: myprobe: (do_filp_open+0x0/0x100) dfd=638399 pathname="/proc/stat"

      irqbalance-1328  [005] .... 2773211.189800: myprobe: (do_filp_open+0x0/0x100) dfd=638399 pathname="/proc/irq/8/smp_affinity"

            bash-15864 [004] .... 2773211.219048: myprobe: (do_filp_open+0x0/0x100) dfd=14819 pathname="/sys/kernel/debug/tracing/"

            bash-15864 [004] .... 2773211.891472: myprobe: (do_filp_open+0x0/0x100) dfd=6859 pathname="/sys/kernel/debug/tracing/"

            bash-15864 [004] .... 2773212.036449: myprobe: (do_filp_open+0x0/0x100) dfd=4294967295 pathname="/sys/kernel/debug/tracing/"

            bash-15864 [004] .... 2773212.197525: myprobe: (do_filp_open+0x0/0x100) dfd=638259 pathname="/sys/kernel/debug/tracing/

…

好了，我们通过 perf 和 ftrace 的几个例子，简单了解了 tracepoint 和 kprobe 是怎么用的。那下面我们再来看看它们的实现原理。

Tracepoint

刚才，我们已经看到了内核函数 do_sys_open() 里调用了 trace_do_sys_open() 这个 treacepoint，那这个 tracepoint 是怎么实现的呢？我们还要再仔细研究一下。

如果你在内核代码中，直接搜索“trace_do_sys_open”字符串的话，并不能找到这个函数的直接定义。这是因为在 Linux 中，每一个 tracepoint 的相关数据结构和函数，主要是通过”DEFINE_TRACE”和”DECLARE_TRACE”这两个宏来定义的。

完整的“DEFINE_TRACE”和“DECLARE_TRACE”宏里，给每个 tracepoint 都定义了一组函数。在这里，我会选择最主要的几个函数，把定义一个 tracepoint 的过程给你解释一下。

首先，我们来看“trace_##name”这个函数（提示一下，这里的“##”是 C 语言的预编译宏，表示把两个字符串连接起来）。

对于每个命名为“name”的 tracepoint，这个宏都会帮助它定一个函数。这个函数的格式是这样的，以“trace_”开头，再加上 tracepoint 的名字。

我们举个例子吧。比如说，对于“do_sys_open”这个 tracepoint，它生成的函数名就是 trace_do_sys_open。而这个函数会被内核函数 do_sys_open() 调用，从而实现了一个内核的 tracepoint。

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 inline void trace_##name(proto)                          \

        {                                                               \

                if (static_key_false(&__tracepoint_##name.key))         \

                        __DO_TRACE(&__tracepoint_##name,                \

                                TP_PROTO(data_proto),                   \

                                TP_ARGS(data_args),                     \

                                TP_CONDITION(cond), 0);                 \

                if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) {             \

                        rcu_read_lock_sched_notrace();                  \

                        rcu_dereference_sched(__tracepoint_##name.funcs);\

                        rcu_read_unlock_sched_notrace();                \

                }                                                       \

        }

在这个 tracepoint 函数里，主要的功能是这样实现的，通过 __DO_TRACE 来调用所有注册在这个 tracepoint 上的 probe 函数。

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

#define __DO_TRACE(tp, proto, args, cond, rcuidle)                      \

…
                it_func_ptr = rcu_dereference_raw((tp)->funcs);         \

                                                                        \

                if (it_func_ptr) {                                      \

                        do {                                            \

                                it_func = (it_func_ptr)->func;          \

                                __data = (it_func_ptr)->data;           \

                                ((void(*)(proto))(it_func))(args);      \

                        } while ((++it_func_ptr)->func);                \

                }

…
…

而 probe 函数的注册，它可以通过宏定义的“register_trace_##name”函数完成。

1
2
3
4
5
6
7
8
9
10
11

static inline int                                               \

register_trace_##name(void (*probe)(data_proto), void *data)    \

{                                                               \

        return tracepoint_probe_register(&__tracepoint_##name,  \

                                        (void *)probe, data);   \

}

我们可以自己写一个简单kernel module来注册一个 probe 函数，把它注册到已有的 treacepoint 上。这样，这个 probe 函数在每次 tracepoint 点被调用到的时候就会被执行。你可以动手试一下。

好了，说到这里，tracepoint 的实现方式我们就讲完了。简单来说就是在内核代码中需要被 trace 的地方显式地加上 hook 点，然后再把自己的 probe 函数注册上去，那么在代码执行的时候，就可以执行 probe 函数。

Kprobe

我们已经知道了，tracepoint 为内核 trace 提供了 hook 点，但是这些 hook 点需要在内核源代码中预先写好。如果在 debug 的过程中，我们需要查看的内核函数中没有 hook 点，就需要像前面 perf/ftrace 的例子中那样，要通过 Linux kprobe 机制来加载 probe 函数。

那我们要怎么来理解 kprobe 的实现机制呢？

你可以先从内核 samples 代码里，看一下

kprobe_example.c代码。这段代码里实现了一个 kernel module，可以在内核中任意一个函数名 / 符号对应的代码地址上注册三个 probe 函数，分别是“pre_handler”、 “post_handler”和“fault_handler”。

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

#define MAX_SYMBOL_LEN   64

static char symbol[MAX_SYMBOL_LEN] = "_do_fork";

module_param_string(symbol, symbol, sizeof(symbol), 0644);
/* For each probe you need to allocate a kprobe structure */

static struct kprobe kp = {

            .symbol_name = symbol,

};
…
static int __init kprobe_init(void)

{

            int ret;

            kp.pre_handler = handler_pre;

            kp.post_handler = handler_post;

            kp.fault_handler = handler_fault;

 

            ret = register_kprobe(&kp);

            if (ret < 0) {

                        pr_err("register_kprobe failed, returned %d\n", ret);

                        return ret;

            }

            pr_info("Planted kprobe at %p\n", kp.addr);

            return 0;

}

当这个内核函数被执行的时候，已经注册的 probe 函数也会被执行 （handler_fault 只有在发生异常的时候才会被调用到）。

比如，我们加载的这个 kernel module 不带参数，那么缺省的情况就是这样的：在“_do_fork”内核函数的入口点注册了这三个 probe 函数。

当 _do_fork() 函数被调用到的时候，换句话说，也就是创建新的进程时，我们通过 dmesg 就可以看到 probe 函数的输出了。

1
2
3
4
5
6
7
8
9
10
11

[8446287.087641] <_do_fork> pre_handler: p->addr = 0x00000000d301008e, ip = ffffffffb1e8c9d1, flags = 0x246

[8446287.087643] <_do_fork> post_handler: p->addr = 0x00000000d301008e, flags = 0x246

[8446288.019731] <_do_fork> pre_handler: p->addr = 0x00000000d301008e, ip = ffffffffb1e8c9d1, flags = 0x246

[8446288.019733] <_do_fork> post_handler: p->addr = 0x00000000d301008e, flags = 0x246

[8446288.022091] <_do_fork> pre_handler: p->addr = 0x00000000d301008e, ip = ffffffffb1e8c9d1, flags = 0x246

[8446288.022093] <_do_fork> post_handler: p->addr = 0x00000000d301008e, flags = 0x246

kprobe 的基本工作原理其实也很简单。当 kprobe 函数注册的时候，其实就是把目标地址上内核代码的指令码，替换成了“cc”，也就是 int3 指令。这样一来，当内核代码执行到这条指令的时候，就会触发一个异常而进入到 Linux int3 异常处理函数 do_int3() 里。

在 do_int3() 这个函数里，如果发现有对应的 kprobe 注册了 probe，就会依次执行注册的 pre_handler()，原来的指令，最后是 post_handler()。

理论上 kprobe 其实只要知道内核代码中任意一条指令的地址，就可以为这个地址注册 probe 函数，kprobe 结构中的“addr”成员就可以接受内核中的指令地址。

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

static int __init kprobe_init(void)

{

        int ret;

        kp.addr = (kprobe_opcode_t *)0xffffffffb1e8ca02; /* 把一条指令的地址赋值给 kprobe.addr */

        kp.pre_handler = handler_pre;

        kp.post_handler = handler_post;

        kp.fault_handler = handler_fault;
        ret = register_kprobe(&kp);

        if (ret < 0) {

                pr_err("register_kprobe failed, returned %d\n", ret);

                return ret;

        }

        pr_info("Planted kprobe at %p\n", kp.addr);

        return 0;

}

还要说明的是，如果内核可以使用我们上一讲 ftrace 对函数的 trace 方式，也就是函数头上预留了“callq <**fentry**>”的 5 个字节（在启动的时候被替换成了 nop）。Kprobe 对于函数头指令的 trace 方式，也会用“ftrace_caller”指令替换的方式，而不再使用 int3 指令替换。

不论是哪种替换方式，kprobe 的基本实现原理都是一样的，那就是把目标指令替换，替换的指令可以使程序跑到一个特定的 handler 里，去执行 probe 的函数。

重点小结

这一讲我们主要学习了 tracepoint 和 kprobe，这两个概念在 Linux tracing 系统中非常重要。

为什么说它们重要呢？因为从 Linux tracing 系统看，我的理解是可以大致分成大致这样三层。

第一层是最基础的提供数据的机制，这里就包含了 tracepoints、kprobes，还有一些别的 events，比如 perf 使用的 HW/SW events。

第二层是进行数据收集的工具，这里包含了 ftrace、perf，还有 ebpf。

第三层是用户层工具。虽然有了第二层，用户也可以得到数据。不过，对于大多数用户来说，第二层使用的友好程度还不够，所以又有了这一层。

很显然，如果要对 Linux 内核调试，很难绕过 tracepoint 和 kprobe。如果不刨根问底的话，前面我们讲的 perf、trace 工具对你来说还是黑盒。因为你只是知道了这些工具怎么用，但是并不知道它们依赖的底层技术。

在后面介绍 ebpf 的时候，我们还会继续学习 ebpf 是如何使用 tracepoint 和 kprobe 来做 Linux tracing 的，希望你可以把相关知识串联起来。

思考题

想想看，当我们用 kprobe 为一个内核函数注册了 probe 之后，怎样能看到对应内核函数的第一条指令被替换了呢？

欢迎你在留言区记录你的思考或者疑问。如果这一讲对你有帮助，也欢迎你转发给同事、朋友，跟他们一起交流、进步。

加餐02 理解perf：怎么用perf聚焦热点函数？

你好，我是程远。今天我要和你聊一聊容器中如何使用 perf。

上一讲中，我们分析了一个生产环境里的一个真实例子，由于节点中的大量的 IPVS 规则导致了容器在往外发送网络包的时候，时不时会有很高的延时。在调试分析这个网络延时问题的过程中，我们会使用多种 Linux 内核的调试工具，利用这些工具，我们就能很清晰地找到这个问题的根本原因。

在后面的课程里，我们会挨个来讲解这些工具，其中 perf 工具的使用相对来说要简单些，所以这一讲我们先来看 perf 这个工具。

问题回顾

在具体介绍 perf 之前，我们先来回顾一下，上一讲中，我们是在什么情况下开始使用 perf 工具的，使用了 perf 工具之后给我们带来了哪些信息。

在调试网路延时的时候，我们使用了 ebpf 的工具之后，发现了节点上一个 CPU，也就是 CPU32 的 Softirq CPU Usage（在运行 top 时，%Cpu 那行中的 si 数值就是 Softirq CPU Usage）时不时地会增高一下。

在发现 CPU Usage 异常增高的时候，我们肯定想知道是什么程序引起了 CPU Usage 的异常增高，这时候我们就可以用到 perf 了。

具体怎么操作呢？我们可以通过抓取数据、数据读取和异常聚焦三个步骤来实现。

第一步，抓取数据。当时我们运行了下面这条 perf 命令，这里的参数 -C 32 是指定只抓取 CPU32 的执行指令；-g 是指 call-graph enable，也就是记录函数调用关系； sleep 10 主要是为了让 perf 抓取 10 秒钟的数据。

1

# perf record -C 32 -g -- sleep 10

执行完 perf record 之后，我们可以用 perf report 命令进行第二步，也就是读取数据。为了更加直观地看到 CPU32 上的函数调用情况，我给你生成了一个火焰图（火焰图的生产方法，我们在后面介绍）。

通过这个火焰图，我们发现了在 Softirq 里 TIMER softirq （run_timer_softirq）的占比很高，并且 timer 主要处理的都是 estimation_timer() 这个函数，也就是看火焰图 X 轴占比比较大的函数。这就是第三步异常聚焦，也就是说我们通过 perf 在 CPU Usage 异常的 CPU32 上，找到了具体是哪一个内核函数使用占比较高。这样在后面的调试分析中，我们就可以聚焦到这个内核函数 estimation_timer() 上了。

好了，通过回顾我们在网络延时例子中是如何使用 perf 的，我们知道了这一点，perf 可以在 CPU Usage 增高的节点上找到具体的引起 CPU 增高的函数，然后我们就可以有针对性地聚焦到那个函数做分析。

既然 perf 工具这么有用，想要更好地使用这个工具，我们就要好好认识一下它，那我们就一起看看 perf 的基本概念和常用的使用方法。

如何理解 Perf 的概念和工作机制？

Perf 这个工具最早是 Linux 内核著名开发者 Ingo Molnar 开发的，它的源代码在内核源码tools 目录下，在每个 Linux 发行版里都有这个工具，比如 CentOS 里我们可以运行 yum install perf 来安装，在 Ubuntu 里我们可以运行 apt install linux-tools-common 来安装。

Event

第一次上手使用 perf 的时候，我们可以先运行一下 perf list 这个命令，然后就会看到 perf 列出了大量的 event，比如下面这个例子就列出了常用的 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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

# perf list

…

  branch-instructions OR branches                    [Hardware event]

  branch-misses                                      [Hardware event]

  bus-cycles                                         [Hardware event]

  cache-misses                                       [Hardware event]

  cache-references                                   [Hardware event]

  cpu-cycles OR cycles                               [Hardware event]

  instructions                                       [Hardware event]

  ref-cycles                                         [Hardware event]

 

  alignment-faults                                   [Software event]

  bpf-output                                         [Software event]

  context-switches OR cs                             [Software event]

  cpu-clock                                          [Software event]

  cpu-migrations OR migrations                       [Software event]

  dummy                                              [Software event]

  emulation-faults                                   [Software event]

  major-faults                                       [Software event]

  minor-faults                                       [Software event]

  page-faults OR faults                              [Software event]

  task-clock                                         [Software event]

…
  block:block_bio_bounce                             [Tracepoint event]

  block:block_bio_complete                           [Tracepoint event]

  block:block_bio_frontmerge                         [Tracepoint event]

  block:block_bio_queue                              [Tracepoint event]

  block:block_bio_remap                              [Tracepoint event]

从这里我们可以了解到 event 都有哪些类型， perf list 列出的每个 event 后面都有一个”[]“，里面写了这个 event 属于什么类型，比如”Hardware event”、”Software event”等。完整的 event 类型，我们在内核代码枚举结构 perf_type_id 里可以看到。

接下来我们就说三个主要的 event，它们分别是 Hardware event、Software event 还有 Tracepoints event。

Hardware event

Hardware event 来自处理器中的一个 PMU（Performance Monitoring Unit），这些 event 数目不多，都是底层处理器相关的行为，perf 中会命名几个通用的事件，比如 cpu-cycles，执行完成的 instructions，Cache 相关的 cache-misses。

不同的处理器有自己不同的 PMU 事件，对于 Intel x86 处理器，PMU 的使用和编程都可以在“Intel 64 and IA-32 Architectures Developer’s Manual: Vol. 3B”（Intel 架构的开发者手册）里查到。

我们运行一下 perf stat ，就可以看到在这段时间里这些 Hardware event 发生的数目。

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

# perf stat

^C

 Performance counter stats for 'system wide':
          58667.77 msec cpu-clock                 #   63.203 CPUs utilized

            258666      context-switches          #    0.004 M/sec

              2554      cpu-migrations            #    0.044 K/sec

             30763      page-faults               #    0.524 K/sec

       21275365299      cycles                    #    0.363 GHz

       24827718023      instructions              #    1.17  insn per cycle

        5402114113      branches                  #   92.080 M/sec

          59862316      branch-misses             #    1.11% of all branches
       0.928237838 seconds time elapsed

Software event

Software event 是定义在 Linux 内核代码中的几个特定的事件，比较典型的有进程上下文切换（内核态到用户态的转换）事件 context-switches、发生缺页中断的事件 page-faults 等。

为了让你更容易理解，这里我举个例子。就拿 page-faults 这个 perf 事件来说，我们可以看到，在内核代码处理缺页中断的函数里，就是调用了 perf_sw_event() 来注册了这个 page-faults。

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

/*

 \* Explicitly marked noinline such that the function tracer sees this as the

 \* page_fault entry point. __do_page_fault 是Linux内核处理缺页中断的主要函数

 */

static noinline void

__do_page_fault(struct pt_regs *regs, unsigned long hw_error_code,

                unsigned long address)

{

        prefetchw(&current->mm->mmap_sem);

 

        if (unlikely(kmmio_fault(regs, address)))

                return;
        /* Was the fault on kernel-controlled part of the address space? */

        if (unlikely(fault_in_kernel_space(address)))

                do_kern_addr_fault(regs, hw_error_code, address);

        else

                do_user_addr_fault(regs, hw_error_code, address); 

                /* 在do_user_addr_fault()里面调用了perf_sw_event() */ 

}
/* Handle faults in the user portion of the address space */

static inline

void do_user_addr_fault(struct pt_regs *regs,

                        unsigned long hw_error_code,

                        unsigned long address)

{

…

     perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);

…

}

Tracepoints event

你可以在 perf list 中看到大量的 Tracepoints event，这是因为内核中很多关键函数里都有 Tracepoints。它的实现方式和 Software event 类似，都是在内核函数中注册了 event。

不过，这些 tracepoints 不仅是用在 perf 中，它已经是 Linux 内核 tracing 的标准接口了，ftrace，ebpf 等工具都会用到它，后面我们还会再详细介绍 tracepoint。

好了，讲到这里，你要重点掌握的内容是，event 是 perf 工作的基础，主要有两种：有使用硬件的 PMU 里的 event，也有在内核代码中注册的 event。

那么在这些 event 都准备好了之后，perf 又是怎么去使用这些 event 呢？前面我也提到过，有计数和采样两种方式，下面我们分别来看看。

计数（count）

计数的这种工作方式比较好理解，就是统计某个 event 在一段时间里发生了多少次。

那具体我们怎么进行计数的呢？perf stat 这个命令就是来查看 event 的数目的，前面我们已经运行过 perf stat 来查看所有的 Hardware events。

这里我们可以加上”-e”参数，指定某一个 event 来看它的计数，比如 page-faults，这里我们看到在当前 CPU 上，这个 event 在 1 秒钟内发生了 49 次：

1
2
3
4
5
6
7

# perf stat -e page-faults -- sleep 1
 Performance counter stats for 'sleep 1':
                49      page-faults
       1.001583032 seconds time elapsed
       0.001556000 seconds user

       0.000000000 seconds sys

采样（sample）

说完了计数，我们再来看看采样。在开头回顾网路延时问题的时候，我提到通过 perf record -C 32 -g -- sleep 10 这个命令，来找到 CPU32 上 CPU 开销最大的 Softirq 相关函数。这里使用的 perf record 命令就是通过采样来得到热点函数的，我们来分析一下它是怎么做的。

perf record 在不加 -e 指定 event 的时候，它缺省的 event 就是 Hardware event cycles。我们先用 perf stat来查看 1 秒钟 cycles 事件的数量，在下面的例子里这个数量是 1878165 次。

我们可以想一下，如果每次 cycles event 发生的时候，我们都记录当时的 IP（就是处理器当时要执行的指令地址）、IP 所属的进程等信息的话，这样系统的开销就太大了。所以 perf 就使用了对 event 采样的方式来记录 IP、进程等信息。

1
2
3

# perf stat -e cycles -- sleep 1
 Performance counter stats for 'sleep 1':
           1878165      cycles

Perf 对 event 的采样有两种模式：

第一种是按照 event 的数目（period），比如每发生 10000 次 cycles event 就记录一次 IP、进程等信息， perf record 中的 -c 参数可以指定每发生多少次，就做一次记录。

比如在下面的例子里，我们指定了每 10000 cycles event 做一次采样之后，在 1 秒里总共就做了 191 次采样，比我们之前看到 1 秒钟 1878165 次 cycles 的次数要少多了。

1
2
3
4
5

# perf record  -e cycles -c 10000 -- sleep 1

[ perf record: Woken up 1 times to write data ]

[ perf record: Captured and wrote 0.024 MB perf.data (191 samples) ]

第二种是定义一个频率（frequency）， perf record 中的 -F 参数就是指定频率的，比如 perf record -e cycles -F 99 -- sleep 1 ，就是指采样每秒钟做 99 次。

在 perf record 运行结束后，会在磁盘的当前目录留下 perf.data 这个文件，里面记录了所有采样得到的信息。然后我们再运行 perf report 命令，查看函数或者指令在这些采样里的分布比例，后面我们会用一个例子说明。

好，说到这里，我们已经把 perf 的基本概念和使用机制都讲完了。接下来，我们看看在容器中怎么使用 perf？

容器中怎样使用 perf？

如果你的 container image 是基于 Ubuntu 或者 CentOS 等 Linux 发行版的，你可以尝试用它们的 package repo 安装 perf 的包。不过，这么做可能会有个问题，我们在前面介绍 perf 的时候提过，perf 是和 Linux kernel 一起发布的，也就是说 perf 版本最好是和 Linux kernel 使用相同的版本。

如果容器中 perf 包是独立安装的，那么容器中安装的 perf 版本可能会和宿主机上的内核版本不一致，这样有可能导致 perf 无法正常工作。

所以，我们在容器中需要跑 perf 的时候，最好从相应的 Linux kernel 版本的源代码里去编译，并且采用静态库（-static）的链接方式。然后，我们把编译出来的 perf 直接 copy 到容器中就可以使用了。

如何在 Linux kernel 源代码里编译静态链接的 perf，你可以参考后面的代码：

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

# cd $(KERNEL_SRC_ROOT)/tools/perf

# vi Makefile.perf

  #### ADD “LDFLAGS=-static” in Makefile.perf

# make clean; make

# file perf

perf: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=9a42089e52026193fabf693da3c0adb643c2313e, with debug_info, not stripped, too many notes (256)

# ls -lh perf

-rwxr-xr-x 1 root root 19M Aug 14 07:08 perf

我这里给了一个带静态链接 perf（kernel 5.4）的 container image例子，你可以运行 make image 来生成这个 image。

在容器中运行 perf，还要注意一个权限的问题，有两点注意事项需要你留意。

第一点，Perf 通过系统调用 perf_event_open() 来完成对 perf event 的计数或者采样。不过 Docker 使用 seccomp（seccomp 是一种技术，它通过控制系统调用的方式来保障 Linux 安全）会默认禁止 perf_event_open()。

所以想要让 Docker 启动的容器可以运行 perf，我们要怎么处理呢？

其实这个也不难，在用 Docker 启动容器的时候，我们需要在 seccomp 的 profile 里，允许 perf_event_open() 这个系统调用在容器中使用。在我们的例子中，启动 container 的命令里，已经加了这个参数允许了，参数是”–security-opt seccomp=unconfined”。

第二点，需要允许容器在没有 SYS_ADMIN 这个 capability（Linux capability 我们在第 19 讲说过）的情况下，也可以让 perf 访问这些 event。那么现在我们需要做的就是，在宿主机上设置出 echo -1 > /proc/sys/kernel/perf_event_paranoid，这样普通的容器里也能执行 perf 了。

完成了权限设置之后，在容器中运行 perf，就和在 VM/BM 上运行没有什么区别了。

最后，我们再来说一下我们在定位 CPU Uage 异常时最常用的方法，常规的步骤一般是这样的：

首先，调用 perf record 采样几秒钟，一般需要加 -g 参数，也就是 call-graph，还需要抓取函数的调用关系。在多核的机器上，还要记得加上 -a 参数，保证获取所有 CPU Core 上的函数运行情况。至于采样数据的多少，在讲解 perf 概念的时候说过，我们可以用 -c 或者 -F 参数来控制。

接着，我们需要运行 perf report 读取数据。不过很多时候，为了更加直观地看到各个函数的占比，我们会用 perf script 命令把 perf record 生成的 perf.data 转化成分析脚本，然后用 FlameGraph 工具来读取这个脚本，生成火焰图。

下面这组命令，就是刚才说过的使用 perf 的常规步骤：

1
2
3
4
5
6
7
8
9

# perf record -a -g -- sleep 60

# perf script > out.perf

# git clone --depth 1 https://github.com/brendangregg/FlameGraph.git

# FlameGraph/stackcollapse-perf.pl out.perf > out.folded

# FlameGraph/flamegraph.pl out.folded > out.sv

重点总结

我们这一讲学习了如何使用 perf，这里我来给你总结一下重点。

首先，我们在线上网络延时异常的那个实际例子中使用了 perf。我们发现可以用 perf 工具，通过抓取数据、数据读取和异常聚焦这三个步骤的操作，在 CPU Usage 增高的节点上找到具体引起 CPU 增高的函数。

之后我带你更深入地学习了 perf 是什么，它的工作方式是怎样的？这里我把 perf 的重点再给你强调一遍：

Perf 的实现基础是 event，有两大类，一类是基于硬件 PMU 的，一类是内核中的软件注册。而 Perf 在使用时的工作方式也是两大类，计数和采样。

先看一下计数，它执行的命令是 perf stat，用来查看每种 event 发生的次数；

采样执行的命令是perf record，它可以使用 period 方式，就是每 N 个 event 发生后记录一次 event 发生时的 IP/ 进程信息，或者用 frequency 方式，每秒钟以固定次数来记录信息。记录的信息会存在当前目录的 perf.data 文件中。

如果我们要在容器中使用 perf，要注意这两点：

1. 容器中的 perf 版本要和宿主机内核版本匹配，可以直接从源代码编译出静态链接的 perf。

2. 我们需要解决两个权限的问题，一个是 seccomp 对系统调用的限制，还有一个是内核对容器中没有 SYC_ADMIN capability 的限制。

在我们日常分析系统性能异常的时候，使用 perf 最常用的方式是perf record获取采样数据，然后用 FlameGraph 工具来生成火焰图。

思考题

你可以在自己的一台 Linux 机器上运行一些带负载的程序，然后使用 perf 并且生成火焰图，看看开销最大的函数是哪一个。

欢迎在留言区分享你的疑惑和见解。你也可以把今天的内容分享给你的朋友，和他一起学习和进步。

加餐福利 课后思考题答案合集

你好，我是程远，好久不见。

距离我们的专栏更新结束，已经过去了不少时间。我仍然会在工作之余，到这门课的留言区转一转，回答同学的问题。大部分的疑问，我都通过留言做了回复。

除了紧跟更新的第一批同学，也很开心有更多新朋友加入到这个专栏的学习中。那课程的思考题呢，为了给你留足思考和研究的时间，我选择用加餐的方式，给你提供参考答案。

这里我想和你说明的是，我这里给你提供的参考答案，都是我能够直接给你特定答案的问题。至于操作类的题目，有的我引用了同学回复的答案。

另外一类操作题，是为了帮你巩固课程内容知识的，相信你可以从课程正文里找到答案。我还是建议你自己动手实战，这样你的收获会更大。

必学部分思考题

第 2 讲

Q：对于这一讲的最开始，有这样一个 C 语言的 init 进程，它没有注册任何信号的 handler。如果我们从 Host Namespace 向它发送 SIGTERM，会发生什么情况呢？

A：即使在宿主机上向容器 1 号进程发送 SIGTERM，在 1 号进程没有注册 handler 的情况下，这个进程也不能被杀死。

这个问题的原因是这样的：开始要看内核里的那段代码，“ !(force && sig_kernel_only(sig))”，

虽然由不同的 namespace 发送信号， 虽然 force 是 1 了，但是 sig_kernel_only(sig) 对于 SIGTERM 来说还是 0，这里是个 &&, 那么 !(1 && 0) = 1。

1
2
3
4
5

#define sig_kernel_only(sig) siginmask(sig, SIG_KERNEL_ONLY_MASK)

#define SIG_KERNEL_ONLY_MASK (\

        rt_sigmask(SIGKILL) | rt_sigmask(SIGSTOP))

第 3 讲

Q：如果容器的 init 进程创建了子进程 B，B 又创建了自己的子进程 C。如果 C 运行完之后，退出成了僵尸进程，B 进程还在运行，而容器的 init 进程还在不断地调用 waitpid()，那 C 这个僵尸进程可以被回收吗？

A：这道题可以参考下面两位同学的回答。

Geek2014 用户的回答：

这时 C 是不会被回收的，只有等到 B 也被杀死，C 这个僵尸进程也会变成孤儿进程，被 init 进程收养，进而被 init 的 wait 机制清理掉。

莫名同学的回答：

C 应该不会被回收，waitpid 仅等待直接 children 的状态变化。

为什么先进入僵尸状态而不是直接消失？觉得是留给父进程一次机会，查看子进程的 PID、终止状态（退出码、终止原因，比如是信号终止还是正常退出等）、资源使用信息。如果子进程直接消失，那么父进程没有机会掌握子进程的具体终止情况。

一般情况下，程序逻辑可能会依据子进程的终止情况做出进一步处理：比如 Nginx Master 进程获知 Worker 进程异常退出，则重新拉起来一个 Worker 进程。

第 4 讲

Q：请你回顾一下基本概念中最后的这段代码，你可以想一想，在不做编译运行的情况下，它的输出是什么？

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

#include <stdio.h>

#include <signal.h>
typedef void (*sighandler_t)(int);
void sig_handler(int signo)

{

        if (signo == SIGTERM) {

                printf("received SIGTERM\n\n");

                // Set SIGTERM handler to default

                signal(SIGTERM, SIG_DFL);

        }

}
int main(int argc, char *argv[])

{

        //Ignore SIGTERM, and send SIGTERM

        // to process itself.
        signal(SIGTERM, SIG_IGN);

        printf("Ignore SIGTERM\n\n");

        kill(0, SIGTERM);
        //Catch SIGERM, and send SIGTERM

        // to process itself.

        signal(SIGTERM, sig_handler);

        printf("Catch SIGTERM\n");

        kill(0, SIGTERM);
        //Default SIGTERM. In sig_handler, it sets

        //SIGTERM handler back to default one.

        printf("Default SIGTERM\n");

        kill(0, SIGTERM);
        return 0;

}

A：可以参考用户 geek 2014 同学的答案。输出结果如下：

Ignore SIGTERM

Catch SIGTERM

received SIGTERM

Default SIGTERM

第 5 讲

Q：我们还是按照文档中定义的控制组目录层次结构图，然后按序执行这几个脚本：

create_groups.sh

update_group1.sh

update_group4.sh

update_group3.sh

那么，在一个 4 个 CPU 的节点上，group1/group3/group4 里的进程，分别会被分配到多少 CPU 呢?

A：分配比例是: 2 : 0.5 : 1.5

可以参考 geek 2014 的答案：

group1 的 shares 为 1024，quota 3.5，尝试使用 4，

group2 的 shares 默认为 1024，quota 设置为 -1，不受限制，也即是，如果 CPU 上只有 group2 的话，那么 group2 可以使用完所有的 CPU（实际上根据 group3 和 group4，group2 最多也就能用到 1.5+3.5 core）

故而，group1 和 group2 各分配到 2。把 group2 分到的 2CPU，看作总量，再次分析 group3 和 group4。group3 和 group3 尝试使用的总量超过 2，所以按照 shares 比例分配，group3 使用 1/(1+3) * 2 = 0.5，group4 使用 3/(1+3) * 2 = 1.5

第 6 讲

Q：写一个小程序，在容器中执行，它可以显示当前容器中所有进程总的 CPU 使用率。

A：上邪忘川的回答可以作为一个参考。

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

#!/bin/bash

cpuinfo1=$(cat /sys/fs/cgroup/cpu,cpuacct/cpuacct.stat)

utime1=$(echo $cpuinfo1|awk '{print $2}')

stime1=$(echo $cpuinfo1|awk '{print $4}')

sleep 1

cpuinfo2=$(cat /sys/fs/cgroup/cpu,cpuacct/cpuacct.stat)

utime2=$(echo $cpuinfo2|awk '{print $2}')

stime2=$(echo $cpuinfo2|awk '{print $4}')

cpus=$((utime2+stime2-utime1-stime1))

echo "${cpus}%"

第 8 讲

Q：在我们的例子脚本基础上，你可以修改一下，在容器刚一启动，就在容器对应的 Memory Cgroup 中禁止 OOM，看看接下来会发生什么？

A：通过“memory.oom_control”禁止 OOM 后，在容器中的进程不会发生 OOM，但是也无法申请出超过“memory.limit_in_bytes”内存。

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

# cat start_container.sh

#!/bin/bash

docker stop mem_alloc;docker rm mem_alloc
docker run -d --name mem_alloc registry/mem_alloc:v1
sleep 2

CONTAINER_ID=$(sudo docker ps --format "{{.ID}}\t{{.Names}}" | grep -i mem_alloc | awk '{print $1}')

echo $CONTAINER_ID
CGROUP_CONTAINER_PATH=$(find /sys/fs/cgroup/memory/ -name "*$CONTAINER_ID*")

echo $CGROUP_CONTAINER_PATH
echo 536870912 > $CGROUP_CONTAINER_PATH/memory.limit_in_bytes

echo 1 > $CGROUP_CONTAINER_PATH/memory.oom_control

cat $CGROUP_CONTAINER_PATH/memory.limit_in_bytes

第 10 讲

Q：在一个有 Swap 分区的节点上用 Docker 启动一个容器，对它的 Memory Cgroup 控制组设置一个内存上限 N，并且将 memory.swappiness 设置为 0。这时，如果在容器中启动一个不断读写文件的程序，同时这个程序再申请 1/2N 的内存，请你判断一下，Swap 分区中会有数据写入吗？

A：Memory Cgroup 参数 memory.swappiness 起到局部控制的作用，因为已经设置了 memory.swappiness 参数，全局参数 swappiness 参数失效，那么容器里就不能使用 swap 了。

第 11 讲

Q：在这一讲 OverlayFS 的例子的基础上，建立 2 个 lowerdir 的目录，并且在目录中建立相同文件名的文件，然后一起做一个 overlay mount，看看会发生什么？

A：这里引用上邪忘川同学的实验结果。

实验过程如下，结果是 lower1 目录中的文件覆盖了 lower2 中同名的文件, 第一个挂载的目录优先级比较高

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

[[[email protected] ~]# cat overlay.sh

#!/bin/bash
umount ./merged

rm upper lower1 lower2 merged work -r
mkdir upper lower1 lower2 merged work

echo "I'm from lower1!" > lower1/in_lower.txt

echo "I'm from lower2!" > lower2/in_lower.txt

echo "I'm from upper!" > upper/in_upper.txt

# `in_both` is in both directories

echo "I'm from lower1!" > lower1/in_both.txt

echo "I'm from lower2!" > lower2/in_both.txt

echo "I'm from upper!" > upper/in_both.txt
sudo mount -t overlay overlay \

 -o lowerdir=./lower1:./lower2,upperdir=./upper,workdir=./work \

 ./merged

[[email protected] ~]# sh overlay.sh

[[email protected] ~]# cat merged/in_lower.txt

I'm from lower1!

第 12 讲

Q：在正文知识详解的部分，我们使用”xfs_quota”给目录打了 project ID 并且限制了文件写入的数据量。那么在做完限制之后，我们是否能用 xfs_quota 命令，查询到被限制目录的 project ID 和限制的数据量呢？

A：xfs_quota 不能直接得到一个目录的 quota 大小的限制，只可以看到 project ID 上的 quota 限制，不过我们可以用这段程序来获得目录对应的 project ID。

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

# xfs_quota -x -c 'report -h /'

...

Project ID   Used   Soft   Hard Warn/Grace

---------- ---------------------------------

#0         105.6G      0      0  00 [------]

#101            0      0    10M  00 [------]
# ./get_proj /tmp/xfs_prjquota

Dir: /tmp/xfs_prjquota projectid is 101

第 13 讲

Q：这是一道操作题，通过这个操作你可以再理解一下 blkio Cgroup 与 Buffered I/O 的关系。

在 Cgroup V1 的环境里，我们在 blkio Cgroup V1 的例子基础上，把 fio 中“-direct=1”参数去除之后，再运行 fio，同时运行 iostat 查看实际写入磁盘的速率，确认 Cgroup V1 blkio 无法对 Buffered I/O 限速。

A: 这是通过 iostat 看到磁盘的写入速率，是可以突破 cgroup V1 blkio 中的限制值的。

第 17 讲

Q：在这节课的最后，我提到“由于 ipvlan/macvlan 网络接口直接挂载在物理网络接口上，对于需要使用 iptables 规则的容器，比如 Kubernetes 里使用 service 的容器，就不能工作了”，请你思考一下这个判断背后的具体原因。

A：ipvlan/macvlan 工作在网络 2 层，而 iptables 工作在网络 3 层。所以用 ipvlan/macvlan 为容器提供网络接口，那么基于 iptables 的 service 服务就不工作了。

第 18 讲

Q：在这一讲中，我们提到了 Linux 内核中的 tcp_force_fast_retransmit() 函数，那么你可以想想看，这个函数中的 tp->recording 和内核参数 /proc/sys/net/ipv4/tcp_reordering 是什么关系？它们对数据包的重传会带来什么影响？

1
2
3
4
5
6
7
8
9
10

static bool tcp_force_fast_retransmit(struct sock *sk)

{

        struct tcp_sock *tp = tcp_sk(sk);
        return after(tcp_highest_sack_seq(tp),

                     tp->snd_una + tp->reordering * tp->mss_cache);

}

A: 在 TCP 链接建立的时候，tp->reordering 默认值是从 /proc/sys/net/ipv4/tcp_reordering（默认值为 3）获取的。之后根据网络的乱序情况，进行动态调整，最大可以增长到 /proc/sys/net/ipv4/tcp_max_reordering (默认值为 300) 的大小。

第 20 讲

Q：我在这一讲里提到了 rootless container，不过对于 rootless container 的支持，还存在着不少的难点，比如容器网络的配置、Cgroup 的配置，你可以去查阅一些资料，看看 podman 是怎么解决这些问题的。

A：可以阅读一下这篇文档。

专题加餐

专题 03

Q：我们讲 ftrace 实现机制时，说过内核中的“inline 函数”不能被 ftrace 到，你知道这是为什么吗？那么内核中的“static 函数”可以被 ftrace 追踪到吗？

A：inline 函数在编译的时候被展开了，所以不能被 ftrace 到。而 static 函数需要看情况，如果加了编译优化参数“-finline-functions-called-once”，对于只被调用到一次的 static 函数也会当成 inline 函数处理，那么也不能被 ftrace 追踪到了。

专题 04

Q：想想看，当我们用 kprobe 为一个内核函数注册了 probe 之后，怎样能看到对应内核函数的第一条指令被替换了呢？

A：首先可以参考莫名同学的答案：

关于思考题，想到一个比较笨拙的方法：gdb+qemu 调试内核。先进入虚拟机在某个内核函数上注册一个 kprobe，然后 gdb 远程调试内核，查看该内核函数的汇编指令（disass）是否被替换。应该有更简单的方法，这方面了解不深。

另外，我们用 gdb 远程调试内核看也可以。还可以通过 /proc/kallsyms 找到函数的地址，然后写个 kernel module 把从这个地址开始后面的几个字节 dump 出来，比较一下 probe 函数注册前后的值。

加餐05 eBPF：怎么更加深入地查看内核中的函数？

你好，我是程远。

今天这一讲，我们聊一聊 eBPF。在我们专题加餐第一讲的分析案例时就说过，当我们碰到网络延时问题，在毫无头绪的情况下，就是依靠了我们自己写的一个 eBPF 工具，找到了问题的突破口。

由此可见，eBPF 在内核问题追踪上的重要性是不言而喻的。那什么是 eBPF，它的工作原理是怎么样，它的编程模型又是怎样的呢？

在这一讲里，我们就来一起看看这几个问题。

eBPF 的概念

eBPF，它的全称是“Extended Berkeley Packet Filter”。从名字看，你可能会觉奇怪，似乎它就是一个用来做网络数据包过滤的模块。

其实这么想也没有错，eBPF 的概念最早源自于 BSD 操作系统中的 BPF（Berkeley Packet Filter），1992 伯克利实验室的一篇论文 “The BSD Packet Filter: A New Architecture for User-level Packet Capture”。这篇论文描述了，BPF 是如何更加高效灵活地从操作系统内核中抓取网络数据包的。

我们很熟悉的 tcpdump 工具，它就是利用了 BPF 的技术来抓取 Unix 操作系统节点上的网络包。Linux 系统中也沿用了 BPF 的技术。

那 BPF 是怎样从内核中抓取数据包的呢？我借用 BPF 论文中的图例来解释一下：

结合这张图，我们一起看看 BPF 实现有哪些特点。

第一，内核中实现了一个虚拟机，用户态程序通过系统调用，把数据包过滤代码载入到个内核态虚拟机中运行，这样就实现了内核态对数据包的过滤。这一块对应图中灰色的大方块，也就是 BPF 的核心。

第二，BPF 模块和网络协议栈代码是相互独立的，BPF 只是通过简单的几个 hook 点，就能从协议栈中抓到数据包。内核网络协议代码变化不影响 BPF 的工作，图中右边的“protocol stack”方块就是指内核网络协议栈。

第三，内核中的 BPF filter 模块使用 buffer 与用户态程序进行通讯，把 filter 的结果返回给用户态程序（例如图中的 network monitor），这样就不会产生内核态与用户态的上下文切换（context switch）。

在 BPF 实现的基础上，Linux 在 2014 年内核 3.18 的版本上实现了 eBPF，全名是 Extended BPF，也就是 BPF 的扩展。这个扩展主要做了下面这些改进。

首先，对虚拟机做了增强，扩展了寄存器和指令集的定义，提高了虚拟机的性能，并且可以处理更加复杂的程序。

其次，增加了 eBPF maps，这是一种存储类型，可以保存状态信息，从一个 BPF 事件的处理函数传递给另一个，或者保存一些统计信息，从内核态传递给用户态程序。

最后，eBPF 可以处理更多的内核事件，不再只局限在网络事件上。你可以这样来理解，eBPF 的程序可以在更多内核代码 hook 点上注册了，比如 tracepoints、kprobes 等。

在 Brendan Gregg 写的书《BPF Performance Tools》里有一张 eBPF 的架构图，这张图对 eBPF 内核部分的模块和工作流的描述还是挺完整的，我也推荐你阅读这本书。图书的网上预览部分也可以看到这张图，我把它放在这里，你可以先看一下。

这里我想提醒你，我们在后面介绍例子程序的时候，你可以回头再来看看这张图，那时你会更深刻地理解这张图里的模块。

当 BPF 增强为 eBPF 之后， 它的应用范围自然也变广了。从单纯的网络包抓取，扩展到了下面的几个领域：

网络领域，内核态网络包的快速处理和转发，你可以看一下XDP（eXpress Data Path）。

安全领域，通过LSM（Linux Security Module）的 hook 点，eBPF 可以对 Linux 内核做安全监控和访问控制，你可以参考KRSI（Kernel Runtime Security Instrumentation）的文档。

内核追踪 / 调试，eBPF 能通过 tracepoints、kprobes、 perf-events 等 hook 点来追踪和调试内核，这也是我们在调试生产环境中，解决容器相关问题时使用的方法。

eBPF 的编程模型

前面说了很多 eBPF 概念方面的内容，如果你是刚接触 eBPF，也许还不能完全理解。所以接下来，我们看一下 eBPF 编程模型，然后通过一个编程例子，再帮助你理解 eBPF。

eBPF 程序其实也是遵循了一个固定的模式，Daniel Thompson 的“Kernel analysis using eBPF”里的一张图解读得非常好，它很清楚地说明了 eBPF 的程序怎么编译、加载和运行的。

结合这张图，我们一起分析一下 eBPF 的运行原理。

一个 eBPF 的程序分为两部分，第一部分是内核态的代码，也就是图中的 foo_kern.c，这部分的代码之后会在内核 eBPF 的虚拟机中执行。第二部分是用户态的代码，对应图中的 foo_user.c。它的主要功能是负责加载内核态的代码，以及在内核态代码运行后通过 eBPF maps 从内核中读取数据。

然后我们看看 eBPF 内核态程序的编译，因为内核部分的代码需要被编译成 eBPF bytecode 二进制文件，也就是 eBPF 的虚拟机指令，而在 Linux 里，最常用的 GCC 编译器不支持生成 eBPF bytecode，所以这里必须要用 Clang/LLVM 来编译，编译后的文件就是 foo_kern.o。

foo_user.c 编译链接后就会生成一个普通的用户态程序，它会通过 bpf() 系统调用做两件事：第一是去加载 eBPF bytecode 文件 foo_kern.o，使 foo_kern.o 这个 eBPF bytecode 在内核 eBPF 的虚拟机中运行；第二是创建 eBPF maps，用于内核态与用户态的通讯。

接下来，在内核态，eBPF bytecode 会被加载到 eBPF 内核虚拟机中，这里你可以参考一下前面的 eBPF 架构图。

执行 BPF 程序之前，BPF Verifier 先要对 eBPF bytecode 进行很严格的指令检查。检查通过之后，再通过 JIT（Just In Time）编译成宿主机上的本地指令。

编译成本地指令之后，eBPF 程序就可以在内核中运行了，比如挂载到 tracepoints hook 点，或者用 kprobes 来对内核函数做分析，然后把得到的数据存储到 eBPF maps 中，这样 foo_user 这个用户态程序就可以读到数据了。

我们学习 eBPF 的编程的时候，可以从编译和执行 Linux 内核中 samples/bpf 目录下的例子开始。在这个目录下的例子里，包含了 eBPF 各种使用场景。每个例子都有两个.c 文件，命名规则都是 xxx_kern.c 和 xxx_user.c ，编译和运行的方式就和我们刚才讲的一样。

本来我想拿 samples/bpf 目录下的一个例子来具体说明的，不过后来我在 github 上看到了一个更好的例子，它就是ebpf-kill-example。下面，我就用这个例子来给你讲一讲，如何编写 eBPF 程序，以及 eBPF 代码需要怎么编译与运行。

我们先用 git clone 取一下代码：

1
2
3
4
5
6
7

# git clone https://github.com/niclashedam/ebpf-kill-example

# cd ebpf-kill-example/

# ls

docs  img  LICENSE  Makefile  README.md  src  test

这里你可以先看一下 Makefile，请注意编译 eBPF 程序需要 Clang/LLVM，以及由 Linux 内核源代码里的 tools/lib/bpf 中生成的 libbpf.so 库和相关的头文件。如果你的 OS 是 Ubuntu，可以运行make deps;make kernel-src这个命令，准备好编译的环境。

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

# cat Makefile

…

deps:

            sudo apt update

            sudo apt install -y build-essential git make gcc clang libelf-dev gcc-multilib
kernel-src:

            git clone --depth 1 --single-branch --branch ${LINUX_VERSION}  https://github.com/torvalds/linux.git kernel-src

            cd kernel-src/tools/lib/bpf && make && make install prefix=../../../../

…

完成上面的步骤后，在 src/ 目录下，我们可以看到两个文件，分别是 bpf_program.c 和 loader.c。

在这个例子里，bpf_program.c 对应前面说的 foo_kern.c 文件，也就是说 eBPF 内核态的代码在 bpf_program.c 里面。而 loader.c 就是 eBPF 用户态的代码，它主要负责把 eBPF bytecode 加载到内核中，并且通过 eBPF Maps 读取内核中返回的数据。

1
2
3

# ls src/

bpf_program.c  loader.c