BPF_MISC+BPF_COP and BPF_COPX

[Darren Reed]

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.

>> <...>
>>
>> No. It's not about calling a function, it is about proving the BPF
>> program is correct and secure.
>>
>> BPF today is essentially assembly language operations that are all
>> easily tested and verified.
>>
>> <...>
>>
>> On 8/08/2013 5:18 AM, Joerg Sonnenberger wrote:
>>> On Thu, Aug 08, 2013 at 01:35:24AM +1000, Darren Reed wrote:
>>>> A BPF program is an entity that can be verified as correct from a
>>>> security perspective.It is also self contained and requires no
>>>> external references in order to understand.
>>>
>>> How is this relevant for the discussion?
>>
>> 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.

>>>> Then add BPF instructions to manipulate address sets (add, remove,
>>>> lookup) and pick a datastore to use to support it.
>>>
>>> How is that more useful than the proposal?
>>
>> 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.

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

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

Darren