tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: BPF_MISC+BPF_COP and BPF_COPX



Darren Reed <darrenr%netbsd.org@localhost> wrote:
> On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote:
> > Darren Reed <darrenr%netbsd.org@localhost> wrote:
> >>>
> >>> You do not have to use it.
> >>
> >> I get no choice - it is in the kernel by default.
> >>
> > 
> > There is no default coprocessor.  Here is your choice: do not call
> > bpf_set_cop(9) and those instructions will effectively be NOPs.
> 
> Anyone with the required privileges to run tcpdump can set this
> coprocessor.

You got it wrong.  Sorry if I was not clear, I will try to clarify
it again: each BPF user (caller) in the *kernel* would have its own
*independent* context (state).  Some user(s) might set and use the
coprocessor, while the others (kernel part providing /dev/bpf) might
not use it.  They would not affect each other.  There is no way to
set the coprocessor at the userlevel (with libpcap or whatever) if
there is no kernel code supporting that.

> >>
> >> It is important to understand what BPF is before making changes to it.
> >>
> ...
> > The reason why we have bpf_validate(9) is to ensure that the byte-code
> > cannot cause any harm to the kernel (whether it is an infinite loop, a
> > crash or any other security vulnerability), because it is passed from
> > the *user*.
> 
> At present it is impossible for there to be an infinite loop because
> it always branches/jumps forward, thus preventing looping behaviour.
> 
> It is this very strictness that makes BPF work and worthwhile.
> 
> Without that, it may as well be Java or some other byte code language.

What kind of strictness are you talking about?  Previously you were
talking about security, now about the capability of the BPF byte-code.
The coprocessor support provides offloading capability.  It does not add
looping capability and no - it does not change BPF to be Turing-complete.

If your point was that we should not consider improvements and conserve
the instruction set from 80s, then we simply disagree. :)

> >> Actually, add/remove are not instructions for the BPF language,
> >> only lookup. Add, remove, etc, would be handled in the usual manner.
> >>
> >> How is that more useful?
> > 
> > You contradict yourself here.  It still calls some "external reference"
> > which you are arguing against.
> 
> Ok, I'll un-contradict myself:
> it shouldn't be possible for BPF to consist of mneumonics that are
> function calls that work on the packet rather than operations on the
> registers/memory. If I implied that this was ok then I was wrong.

Can you provide a justification for this?

> Have you presented why this approach that you've embarked on is
> required and others do not work?

It provides way much greater flexibility, or rather - it provides the
flexibility, while your solution does not.

> 
> Is it trying to deal with a limitation/problem in npf?

Not at all.  This is to avoid code duplication.  It is BPF which has a
limitation and BPF_COP is a clean way (design wise) to address it.

-- 
Mindaugas


Home | Main Index | Thread Index | Old Index