Re: endianness of portable BPF bytecode

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

> --- Begin Message ---
>
>
> From: Denis Ovsienko <denis () ovsienko info>
>
> Date: Sat, 11 Jun 2022 19:19:47 +0100
>
> On Sat, 11 Jun 2022 10:51:41 -0400
> Michael Richardson <mcr () sandelman ca> wrote:
>
> > 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).  
> >
> > 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
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers