In some email I received from Jason R Thorpe, sie wrote:
> On Fri, Dec 29, 2000 at 11:24:59PM +1100, Darren Reed wrote:
> 
>  > But quite secure given that they can't be deleted.  Well, you can insert
>  > in front of said rules but some flexibility won't go astray.  As for it
>  > being safe, well, it may not get validated but the automatically generated
>  > code is otherwise just as `safe' as any other kernel C code.
> 
> ....right, for the "statically compiled into the kernel" type rules,
> they're just as safe as any other code statically compiled into the
> kernel.  But having to reboot to adjust rules is just not acceptable
> in many applications.

Like I said, you can insert before it (or add after for that matter).
It `compiles' n ipf.conf rules into 1 single rule that is a function call.
You can't delete that one, but you can insert before it or add after it.

Only slightly less inconvienient than having to shutdown to single user
mode because adding/removing of rules isn't allowed at the securelevel
you are running at (this is often a reboot anyway).

>  > Whilst bpf_validate() checks bytecode, what checks the resulting
>  > object code for correctness ?
> 
> Regression testing on the synthesizer.
> 
> The point it is BPF bytecode that is being loaded into the kernel, the
> kernel then validates that the bytecode is safe (no infinite loops, no
> jumping to outside the bytecode program's boundaries, etc.), and then
> the kernel takes this trusted bytecode and translates it into object
> code.  The kernel doesn't get object code (which it would not be able
> to easily verify) loaded into it.

What/who verifies what the kernel generates ?

Darren