Berkeley Packet Filter
||This article has multiple issues. Please help improve it or discuss these issues on the talk page.
The Berkeley Packet Filter or BPF provides, on some Unix-like systems, a raw interface to data link layers, permitting raw link-layer packets to be sent and received. In addition, if the driver for the network interface supports promiscuous mode, it allows the interface to be put into that mode, so that all packets on the network, even those destined for other hosts, can be received.
In addition, it supports "filtering" packets, so that only "interesting" packets can be supplied to the software using BPF; this can avoid copying "uninteresting" packets from the operating system kernel to software running in user mode, reducing the CPU requirement to capture packets and the buffer space required to avoid dropping packets. BPF's filtering capabilities are implemented as an interpreter for a machine language for the BPF virtual machine; programs in that language can fetch data from the packet, perform arithmetic operations on data from the packet, and compare the results against constants or against data in the packet or test bits in the results, accepting or rejecting the packet based on the results of those tests. On some platforms, including FreeBSD and WinPcap, just-in-time compilation is used to convert virtual machine instructions into native code in order to further avoid overhead.
Kernel-mode interpreters for that same virtual machine language are used in raw data link layer mechanisms in other operating systems, such as Tru64 Unix, and for socket filters in Linux and in the WinPcap packet capture mechanism.
A user-mode interpreter for it is provided with the libpcap/WinPcap implementation of the pcap application programming interface (API), so that, when capturing packets on systems without kernel-mode support for that filtering mechanism, packets can be filtered in user mode; code using the pcap API will work on both types of systems, although, on systems where the filtering is done in user mode, all packets, including those that will be filtered out, are copied from the kernel to user space. That interpreter can also be used when reading a file containing packets captured using pcap.
BPF is sometimes used to refer just to the filtering mechanism, rather than to the entire interface.
BSD kernels implement routines such as
bpf_tap(), with some wrapping them in macros such as
BPF_TAP(), which are called by network interface drivers (and pseudo-drivers) to deliver incoming and outgoing packets to the BPF mechanism.
In August 2003, SCO Group publicly claimed to own Unix code which they alleged the Linux kernel infringed. Programmers quickly discovered the code in question was the Berkeley Packet Filter. While clear that SCO did not own the BPF code, they did not explain or acknowledge the mistake, although legal action is ongoing that may eventually force an answer.
In 2007, Robert Watson and Christian Peron added zero-copy buffer extensions to the BPF implementation in the FreeBSD operating system, allowing kernel packet capture in the device driver interrupt handler to write directly to user process memory in order to avoid the requirement for two copies for all packet data received via the BPF device. While one copy remains in the receipt path for user processes, this preserves the independence of different BPF device consumers, as well as allowing the packing of headers into the BPF buffer rather than copying complete packet data.