Re: BPF_MISC+BPF_COP and BPF_COPX (summary and patch)

[Darren Reed <darrenr%netbsd.org@localhost>]

On Thu, Aug 29, 2013, at 05:27 PM, Mindaugas Rasiukevicius wrote:
> Darren Reed <darrenr%netbsd.org@localhost> wrote:
> > Mindaugas Rasiukevicius wrote:
> > > Hi,
> > >
> > > OK, to summarise what has been discussed:
> > >
> > > - Problem
> > >
> > > There is a need to perform more complex operations from the BPF program.
> > > Currently, there is no (practical) way to do that from the byte-code.
> > > Such functionality is useful for the packet filters or other components,
> > > which could integrate with BPF.  For example, while most of the packet
> > > inspection logic can stay in the byte-code, such operations as looking
> > > up an IP address in some container or walking the IPv6 headers and
> > > returning some offsets have to be done externally.  The first existing
> > > user of such capability would be NPF in NetBSD.
> > >   
> > 
> > I'd argue that the IPv6 problem is of such a generic nature that
> > it deserves its own instruction/s. We may look at IPv6 today and
> > think nobody uses it much but over time that is going to change.
> > Thus there will be an outcome not possible with co-processor
> > approach if an instruction is created for that purpose and is
> > common across all platforms through libpcap. Unless the IPv6
> > problem is too complex for a single instruction (this has not
> > been demonstrated.) In that case maybe BPF itself needs to evolve
> > such that it can support more complex instructions.
> 
> This is a separate issue.  Feel free to propose an new instruction to
> parse IPv6 headers.

To do this requires understanding what we want to do with
the extension headers. Do we want to:
1) find a particular extension header
2) find the start of the last extension header
3) get a list of all extension headers (including L4 protocols)
4) as per (3) but also their offset
5) ... anything else?

For example, if you were to write a tcpdump expression to filter
fragments for IPv6, what should the BPF look like?

Alternatively if you wanted to display all packets that had both a
routing header, fragment header and were UDP, how complex
should the BPF instruction set that results be?

> > The current implementation of BPF makes it very hard to expand
> > the instruction set without impinging on the ability to make
> > future changes due to the way in which instructions are codified
> > into 32bits. Whilst the method of supporting a co-processor gets
> > around that, it does so in such a generic fashion that it becomes
> > too easy to use it as a bit-bucket for anything you think might
> > be a good idea if BPF could do without really evaluating if it
> > should do.
> 
> It is certainly possible that some operations, which will be
> implemented using BPF coprocessor, will be useful in general.
> Again, whether such operations should be "promoted" to be
> new BPF instructions or there should be a global "standardised"
> coprocessor or how BPF should evolve (including RISC vs
> CISC-like instruction set debate) is a separate discussion.

Oh, my comment above was much more open than that.

Effectively what I'm proposing is moving beyond the single
32bit instruction word for BPF: maybe it is time for BPF to
join the 64bit world.

The current design of BPF enforces a certain amount of rigour
because it can't be expanded ad-hoc due to the design and
the implementation of that design. It forces you to consider
"should I do it" not just "can I do it."

My comment above about the "should" part refers to the
co-processor argument taking away a certain amount of
engineering discipline that currently goes with BPF.
Currently you can't just use it for "anything and everything."

Cheers,
Darren