tech-net archive

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


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

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


Home | Main Index | Thread Index | Old Index