Re: endianness of portable BPF bytecode

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Fri, 10 Jun 2022 14:26:34 -0700
>
> On Jun 10, 2022, at 1:59 PM, Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
>
> > Below is a draft of such a file format.  It addresses the following
> > needs:
> > * There is a header with a signature string to avoid false positive
> >  detection as some other file type that begins exactly with particular
> >  bytecode (ran into this during disassembly experiments).
> > * There are version fields to address possible future changes to the
> >  encoding (either backward-compatible or not).
>
> Is the idea that a change that's backward-compatible (so that code that handles the new format needs no changes to 
> handle the old format, but code that handles only the old format can't handle the new format) would involve a change to 
> the minor version number, but a change that's not backward-compatible (so that to handle both versions would require 
> two code paths for the two versions) would involve a change to the major version number?
>
> > File format:
> >
> > 0                   1                   2                   3
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |      'c'      |      'B'      |      'P'      |      'F'      |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Is the 'c' part of the retronym "cBPF" for the "classic BPF" instruction set, as opposed to the eBPF instruction set?  
> (I didn't find any file format for saving eBPF programs, so this format could be used for that as well, with the magic 
> number 'e' 'B' 'P' 'F'.)
>
> > Type=0x02 (LINKTYPE_ID)
> > Length=4
> > Value=<integer, link-layer header type>
>
> This could be 2 bytes long - pcapng limits link-layer types to 16 bits, and pcap now can use the upper 16 bits of the 
> link-layer type field for other purposes.
>
> > Type=0x03 (LINKTYPE_NAME)
> > Length is variable
> > Value=<ASCII string, the link-layer header type name>
>
> E.g. either its LINKTYPE_xxx name or its DLT_xxx name?
>
> > Type=0x04 (COMMENT)
> > Length is variabe
> > Value=<UTF-8 string, comment or the generating software description>
>
> "Generating software description" as in the code that generated the BPF program?
>
> > Type=0x05 (TIMESTAMP)
> > Length=8
> > Value=<integer, Unix timestamp>
>
> Is this the time the code was generated?
>
> Is it a 64-bit time_t, or a 32-bit time_t and a 32-bit microseconds/nanoseconds value?  I'd recommend the former, 
> unless we expect classic BPF to be dead by 2038.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers