[tcpdump-workers] endianness of portable BPF bytecode

Denis Ovsienko denis at ovsienko.info
Sat Jun 11 14:19:47 EDT 2022


On Sat, 11 Jun 2022 10:51:41 -0400
Michael Richardson <mcr at sandelman.ca> wrote:

> Denis Ovsienko via tcpdump-workers
> <tcpdump-workers at 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).  
> 
> Looks good, but I suggest that rather than 'savefile', that it
> contain something about the program that wrote it, and then a CRC32
> on the first 12 bytes.
> That protects against a .txt file that starts with with cBPFsavefile
> :-)

Thank you for the feedback.  The essential thing is to declare what the
file is, in that sense I agree a binary marker would work better.  It
could be, for example, 0xa1, 0xb2, 0xc3, 0xcb (along the lines of
sf-pcap.c, but not yet taken).  With that in place, the program that
generates the file can leave a "XYZ BPF compiler was 'ere" string in an
optional TLV, if it wants.

The CRC is an interesting point, but it would need to cover more data
to make a meaningful difference in the sense of data integrity.  Thus it
would need to be as close to the end of file as possible in order not
to block/buffer subsequent output data (fseek() does not work on pipes).
This way, to be a part of the initial version, the CRC would need to be
very carefully defined.

> https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/ is
> waiting on editing, and deals with these issues from a CBOR point of
> view. Instructions *could* just be a CBOR array or CBOR arrays

Maybe in a later version.  Let's keep the initial encoding as simple as
possible, for both reading and writing.

> > TLV format:  
> 
> I'm really not keen for Yet-Another-TLV format.
> I don't think that the disk space is so constrained to use 24-bits
> rather than 32-bits for the TL header.

Fine, let it be 16+16 bits then.

-- 
    Denis Ovsienko


More information about the tcpdump-workers mailing list