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