endianness of portable BPF bytecode

[Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Denis Ovsienko <denis () ovsienko info>
>
> Date: Thu, 2 Jun 2022 20:58:38 +0100
>
> 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
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers