Linux内核工程导论——网络：Filter（LSF、BPF）

数据包过滤

    LSF(Linux socket filter)起源于BPF（Berkeley Packet Filter），基础从架构一致，但使用更简单。其核心原理是对用户提供了一种SOCKET选项：SO_ATTACH_FILTER。允许用户在某个sokcet上添加一个自定义的filter，只有满足该filter指定条件的数据包才会上发到用户空间。因为sokket有很多种，你可以在各个维度的socket添加这种filter，如果添加在raw socket，就可以实现基于全部IP数据包的过滤（tcpdump就是这个原理），如果你想做一个http分析工具，就可以在基于80端口（或其他http监听端口）的socket添加filter。还有一种使用方式离线式的，使用libpcap抓包存储在本地，然后可以使用bpf代码对数据包进行离线分析，这对于实验新的规则和测试bpf程序非常有帮助。甚至更底层的用法，可以在内核模块中直接写eBPF（内核中的表达方法，后面介绍）程序，直接插入内核的执行流程。

echo 2 > /proc/sys/net/core/bpf_jit_enable

通过像这个写入0/1/2可以实现关闭、打开、调试日志等bpf模式。

    在用户空间使用，最简单的办法是使用libpcap的引擎，由于bpf是一种汇编类型的语言，自己写难度比较高，所以libpcap提供了一些上层封装可以直接调用。然而libpcap并不能提供所有需求，比如bpf模块开发者的测试需求，还有高端的自定义bpf脚本的需求。这种情况下就需要自己编写bpf代码，然后使用内核tools/net/目录下的工具进行编译成bpf汇编代码，再使用socket接口传入这些代码即可。bpf引擎在内核中大部分以模块的形式提供，并且可以替换采用不同的引擎，常用的由netfilter自带的xt_bpf 、cls_bpf，
    内核对bpf的完整支持是从3.9开始的，作为iptables的一部分存在，默认使用的是xt_bpf，用户端的库是libxt_bpf。iptables一开始对规则的管理方式是顺序的一条条的执行，这种执行方式难免在匹配数目多的时候带来性能瓶颈，添加了bpf支持后，灵活性大大提升。

其他的BPF程序

    前面说的bpf程序是用来做包过滤的，那么bpf代码只能用来做包过滤吗？非也。内核的bpf支持是一种基础架构，只是一种中间代码的表达方式，是向用户空间提供一个向内核注入可执行代码的公共接口。只是目前的大部分应用是使用这个接口来做包过滤。其他的如seccomp BPF可以用来实现限制用户进程可使用的系统调用，cls_bpf可以用来将流量分类，PTP dissector/classifier（干啥的还不知道）等都是使用内核的eBPF语言架构来实现各自的目的，并不一定是包过滤功能。

用户空间bpf支持

工具：tcpdump、tools/net、cloudfare、seccomp BPF

用户空间bpf汇编架构分析

    bpf中每一条汇编指令都是如下格式：

struct sock_filter {    /* Filter block */
    __u16   code;   /* Actual filter code */
    __u8    jt; /* Jump true */
    __u8    jf; /* Jump false */
    __u32   k;      /* Generic multiuse field */
};

    一个列子：op:16, jt:8, jf:8, k:32
    code是真实的汇编指令，jt是指令结果为true的跳转，jf是为false的跳转，k是指令的参数，根据指令不同不同。一个bpf程序编译后就是一个sock_filter的数组，而可以使用类似汇编的语法进行编程，然后使用内核提供的bpf_asm程序进行编译。
    bpf在内核中实际上是一个虚拟机，有自己定义的虚拟寄存器组。和我们熟悉的java虚拟机的原理一致。这个虚拟机的设计是lsf的成功的所在。有3种寄存器：

  A           32位，所有加载指令的目的地址和所有指令运算结果的存储地址
  X           32位，二元指令计算A中参数的辅助寄存器（例如移位的位数，除法的除数）
  M[]         0-15共16个32位寄存器，可以自由使用

    我们最常见的用法莫过于从数据包中取某个字的数据内来做判断。按照bpf的规定，我们可以使用偏移来指定数据包的任何位置，而很多协议很常用并且固定，例如端口和ip地址等，bpf就为我们提供了一些预定义的变量，只要使用这个变量就可以直接取值到对应的数据包位置。例如：

  len                                   skb->len
  proto                                 skb->protocol
  type                                  skb->pkt_type
  poff                                  Payload start offset
  ifidx                                 skb->dev->ifindex
  nla                                   Netlink attribute of type X with offset A
  nlan                                  Nested Netlink attribute of type X with offset A
  mark                                  skb->mark
  queue                                 skb->queue_mapping
  hatype                                skb->dev->type
  rxhash                                skb->hash
  cpu                                   raw_smp_processor_id()
  vlan_tci                              skb_vlan_tag_get(skb)
  vlan_avail                            skb_vlan_tag_present(skb)
  vlan_tpid                             skb->vlan_proto
  rand                                  prandom_u32()

更可贵的是这个列表还可以由用户自己去扩展。各种bpf引擎的具体实现还会定义各自的扩展。

内核的BPF支持

    我们可以看到，用户端即使经过编译的bpf代码也只是内核的一个结构体数组，与具体的可执行的实际汇编代码还是有差距的。要想得到可以直接执行的二进制代码，还需要在内核中进行编译。首先是将用户提交来的结构体数组进行编译成eBPF代码。这个代码是内核层级的虚拟汇编代码，这套汇编代码不用用户自己写，而是用户需要完成的只是sock_filter结构体数组，后面的转换为eBPF代码是内核自己完成的。然后再将eBPF代码转变为可直接执行的二进制。在eBPF之前的内核表达方法叫classic BPF format，这在很多平台还在使用，这个代码就和用户空间使用的那种汇编是一样的，但是在X86架构，现在在内核态已经都切换到使用eBPF作为中间语言了。也就是说x86在用户空间使用的汇编和在内核空间使用的并不一样。但是内核在定义eBPF的时候已经尽量的复用bpf的编码，有的指令的编码和意义，如BPF_LD都是完全一样的。
    所以可以看出，eBPF的野心绝不止于此， 作为一种内核中存在的平台中间语言，他希望将所有用户希望在内核中执行的代码逻辑编译成eBPF。

内核eBPF汇编架构分析

`
* R0 - return value from in-kernel function, and exit value for eBPF program
* R1 - R5 - arguments from eBPF program to in-kernel function
* R6 - R9 - callee saved registers that in-kernel function will preserve
* R10 - read-only frame pointer to access stack

`
    为了配合更强大的功能，eBPF汇编架构使用的寄存器有所增加，上述的寄存器的存在，充分体现了函数调用的概念，而不再是加载处理的原始逻辑。有了函数调用的逻辑设置可以直接调用内核内部的函数（这是一个安全隐患，但是内部有规避机制）。不但如此，由于这种寄存器架构与x86等CPU的真实寄存器架构非常像，实际的实现正是实行了直接的寄存器映射，也就是说这些虚拟的寄存器实际上是使用的同功能的真实的寄存器，这无疑是对效率的极大提高。而且，在64位的计算机上这些计算机将会有64位的宽度，完美的发挥硬件能力。但是目前的64位支持还不太完善，但已经可用。
    目前的内核实现，只可以在eBPF程序中调用预先定义好的内核函数，不可以调用其他的eBPF程序(因为eBPF本身不是函数的概念)。这看起来无关紧要，但是却是一个极大的能力，这就意味着你可以使用C语言来实现eBPF程序逻辑，eBPF只需要调用这个C函数就好了。

eBPF的数据交互：map

    eBPF不但是程序，还可以访问外部的数据，重要的是这个外部的数据可以在用户空间管理。这个k-v格式的map数据体是通过在用户空间调用bpf系统调用创建、添加、删除等操作管理的。

eBPF的直接编程方法

除了在用户空间通过nettable和tcpdump来使用bpf，在内核中或者在其他通用的编程中可以直接使用C写eBPF代码，但是需要LLVM支持，例子。

在用户空间通过使用bpf系统调用的BPF_PROG_LOAD方法，就可以发送eBPF的代码进内核，如此发送的代码不需要再做转换，因为其本身就是eBPF格式的。如果要在内核空间模块使用eBPF，可以直接使用对应的函数接口插入eBPF程序到sk_buff，提供强大的过滤能力。

用于内核TRACING

    我们知道eBPF有map数据结构，有程序执行能力。那么这就是完美的跟踪框架。比如通过kprobe将一个eBPF程序插入IO代码，监控IO次数，然后通过map向用户空间汇报具体的值。用户端只需要每次使用bpf系统调用查看这个map就可以得到想要统计的内容了。那么为何要用eBPF，而不是直接使用kprobe的c代码本身呢？这就是eBPF的安全性，其机制设计使其永远不会crash掉内核，不会与正常的内核逻辑发生交叉影响。可以说，通过工具选择避免了可能发生的很多问题。更可贵的是eBPF是原生的支持tracepoint，这就为kprobe不稳定的情况提供了可用性。

业界对eBPF的使用

Brendan Gregg’s Blog 描述了一个使用eBPF进行kprobe测试的例子。
ktap创造性的使用eBPF机制实现了内核模块的脚本化，使用ktap，你可以直接使用脚本编程，无需要编译内核模块，就可以实现内核代码的追踪和插入。这背后就是eBPF和内核的tracing子系统。
bpf subcommand to perf：华为也在为bpf添加perf脚本的支持能力。
可以看出来，eBPF起源于包过滤，但是目前在trace市场得到越来越广泛的应用。

意义和总结

也就是说目前使用传统的bpf语法和寄存器在用户空间写bpf代码，代码在内核中会被编译成eBPF代码，然后编译为二进制执行。传统的bpf语法和寄存器简单，更面向业务，类似于高层次的编程语言，而内核的eBPF语法和寄存器复杂，类似于真实的汇编代码。
那么为何内核要大费周章的实现如此一个引擎呢？因为轻量级、安全性和可移植性。由于是中间代码，可移植性不必说，但是使用内核模块调用内核的函数接口一般也是可移植的，所以这个并不是很重要的理由。eBPF代码在执行的过程中被严格的限制了禁止循环和安全审查，使得eBPF被严格的定位于提供过程式的执行语句块，甚至连函数都算不上，并且限制同时只有一个eBPF程序，最大不超过4096个指令。所以这就是其定位：轻量级、安全、不循环。
上面说了几个bpf的用途，但远不至于此。

http://www.tcpdump.org/papers/bpf-usenix93.pdf
http://lwn.net/Articles/498231/
https://www.kernel.org/doc/Documentation/networking/filter.txt