Re: BPF_MISC+BPF_COP and BPF_COPX

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

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.

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

It is *your* understanding with a premise you just came up.  I do not
think that your premise is universally accepted.

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*.  The fundamental difference is that the coprocessor comes
from the *kernel*.  We tend to trust that the kernel is not self-harming
and compilers do constructive job.  We cannot validate that (unless you
want to challenge Turing's halting problem), but the point being is that
we do not need to.

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

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

When I was thinking of BPF_COP/BPF_COPX, I was thinking of MIPS.  The
capability of the opcodes does not have to be programmed into the BPF
program.  You still have a core set of BPF instructions which will work
everywhere and there is a reason why we have BPF_MISC.  I can understand
the concern about platforms implementing different behaviour, but your
proposal of adding an instruction for every specific operation is not
going to help.  It is a question of agreement (hence CC freebsd-net).

-- 
Mindaugas