[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BPF_MISC+BPF_COP and BPF_COPX
On 9/08/2013 12:17 AM, Mindaugas Rasiukevicius wrote:
> 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
> 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.
Main Index |
Thread Index |