BPF_MISC+BPF_COP and BPF_COPX

[Darren Reed]

On 9/08/2013 12:17 AM, Mindaugas Rasiukevicius wrote:
> Darren Reed <darrenr at netbsd.org> wrote:
>> On 8/08/2013 9:14 PM, Mindaugas Rasiukevicius wrote:
>>> Darren Reed <darrenr at netbsd.org> 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.

Rather than try explaining it across an email thread, maybe the
design should be presented fully and accompany a problem description.

>> 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 strictness that makes it impossible for there to be infinite loops
(for example.) That strictness also imparts security.

> The coprocessor support provides offloading capability.

Yes, it does...

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

No, improvements in BPF are required for IPv6, e.g.
http://permalink.gmane.org/gmane.network.tcpdump.devel/5141

>> 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?

Because then BPF ceases to be a language that can be verified
for security, reliability and performance purposes.

>> 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.

Maybe you should start this proposal properly with a problem
description and how this solves it. There isn't nearly enough
information in what has been presented to properly understand
what has been proposed.

Darren