Re: BPF_MISC+BPF_COP and BPF_COPX

[Darren Reed <darrenr%netbsd.org@localhost>]

On 8/08/2013 3:55 AM, Mindaugas Rasiukevicius wrote:
> Darren Reed <darrenr%netbsd.org@localhost> wrote:
>>>
>>> I would like propose new BPF instructions for the misc category: BPF_COP
>>> and BPF_COPX.  It would provide a capability of calling an external
>>> function - think of BPF "coprocessor".
>>
>> No.
>>
> 
> You do not have to use it.

I get no choice - it is in the kernel by default.

>> 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.
>>
>> This change brakes the BPF security model because now the BPF program
>> is calling out to some random function as part of the packet matching.
> 
> BPF byte-code can still be verified.  You cannot call random functions,
> the functions are predetermined and cannot change during the life-cycle.
>
> There is a difference.  However, it is as secure as calling any other
> function in the kernel on packet transmission.  You can make a bug in
> your function, but you can as well make it in tcp_input().

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.

>>> It provides us a capability to offload more complex packet processing.
>>> My primary user would be NPF in NetBSD, e.g. one of the operations is to
>>> lookup an IP address in a table/ipset.
>>
>> Then add BPF instructions to manipulate address sets (add, remove, lookup)
>> and pick a datastore to use to support it.
> 
> How adding specialised random instructions is better than having a generic
> mechanism?  You mean BPF_SOME_LOOKUP calling some_lookup() suddenly becomes
> more secure than BPF_MISC+BPF_COP calling the same some_lookup()?

See below.

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.

>>> It provides us a capability to offload more complex packet processing.
>>> My primary user would be NPF in NetBSD, e.g. one of the operations is to
>>> lookup an IP address in a table/ipset.
>>
>> 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?

The capability of the opcodes is programmed into the BPF program,
not through some external reference. A BPF program generated on
Linux is just as valid as on Solaris or NetBSD. Whilst that may
be meaningless because nobody copies BPF programs around (in byte
code format), this would open a door on developing specialised
behaviour for "my platform" that isn't present elsewhere. This
then diminishes the value of BPF.

> The BPF design has some serious limitations for modern network
> protocols. For example, the forward-jump-only property makes it
> impossible to write rules for protocols with arbitrary header
> composition. While it is not desirable to completely remove this
> restriction, the proposal could help to deal with many of the
> interesting case efficently.

Correct. The forward jumping only aspect is an important attribute
of BPF as it bounds the amount of time that the system can spend
on processing the packet. Given that BPF opcodes are evaluated in
the hot patch of packet processing, that kind of guarantee is very
important.

I think your reference here to arbitrary header ordering is in
reference to IPv6 - which actually does have some rules about
in which order headers can be found. Just as IPv4 has a special
instruction with which to find the start of a transport header,
I see no reason why something similar shouldn't exist for IPv6.

The challenge becomes to think of processing the packet differently
and how the relationship between BPF and the packet dictates what
instructions are necessary.

Darren