所以BPF程序是内核实体，因为它们在内核空间中运行。另一方面，Linux 命名空间又名容器，提供应用程序级别的隔离，在这种情况下，它们都共享主机的内核、内核模块等。
所以我想每个容器加载一个程序是没有意义的bpf，因为它也会在主机上变得可见？
因此，我猜想bpf程序会加载到主机和监视器/mangle/等上。进出命名空间的数据包。鉴于struct sock有关于命名空间 id 的信息，我认为只有某些类型的bpf程序才能做到这一点？
问问题
969 次
1 回答
6
所以我想每个容器加载一个程序是没有意义的
bpf，因为它也会在主机上变得可见？
如果您的意思是从容器中加载 BPF 程序，那么是的，它也将在主机上可见（并且您需要一个特权容器才能做到这一点）。
鉴于
struct sock有关于命名空间 id 的信息，我认为只有某些类型的bpf程序才能做到这一点？
我找不到任何可以直接访问struct sock. sockops 类型的 BPF 程序可以访问struct bpf_sock，但它包含的实际信息很少。
不过，您可以使用cgroup/skb 类型的 BPF 程序。这些附加到 cgroups 并且可以作用于入口和出口数据包。他们接收一个struct __sk_buff对象作为参数，是sk_buff接收/发送数据包的镜像。他们只能使用几个助手（除了公共基础），并且似乎没有对数据包的写访问权。
kprobe BPF 程序可以访问任何可以附加 kprobes 的内核函数。因此，您可以通过探测适当的函数来检索命名空间信息，然后将其发送到您的监视器/mangle/等。通过 bpf 映射编程。虽然不是最简单的选择。
于 2018-02-19T14:08:21.273 回答