[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: BPF_MISC+BPF_COP and BPF_COPX
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).
Main Index |
Thread Index |