endianness of portable BPF bytecode
denis at ovsienko.info
Thu Jun 2 15:58:38 EDT 2022
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:
Also in Radare2 (which might be handy for BPF bytecode disassembly)
the code does not seem to be entirely certain about the input data
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.
More information about the tcpdump-workers