endianness of portable BPF bytecode

Denis Ovsienko denis at ovsienko.info
Thu Jun 2 15:58:38 EDT 2022


Hello list.

In the usual workflow a correct BPF expression eventually compiles to a
series of BPF instructions, each of which is a 64-bit structure
encoding the (opcode, jt, jf, k) tuple.

So long as the compiled bytecode appears only between the OS kernel and
libpcap, its endianness has a limited scope.  However, as soon as the
bytecode needs to be saved to a portable file (or fed through a pipe or
a socket), it needs either to abide by an endianness convention, or to
use a header indicator such as the one in pcap-savefile(5).  There is a
couple open requests that would require this to be specified:

https://github.com/the-tcpdump-group/libpcap/issues/211
https://github.com/the-tcpdump-group/libpcap/pull/353

Also in Radare2 (which might be handy for BPF bytecode disassembly)
the code does not seem to be entirely certain about the input data
endianness.

As far as it was possible to infer from the 1993 Usenix paper, the
original development of BPF was done entirely on big-endian systems.
If there is no convention in place yet, I would like to propose
declaring big-endian as the implicit/default byte order, then
particular file format(s) with headers can override that as needed.

-- 
    Denis Ovsienko


More information about the tcpdump-workers mailing list