Re: BPF_MISC+BPF_COP and BPF_COPX

[Alexander Nasonov <alnsn%yandex.ru@localhost>]

Mindaugas Rasiukevicius wrote:
> Hello,
> 
> 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".  The argument for BPF_COP is an
> index to a pre-loaded array of function pointers.  BPF_COPX takes the
> function index from the register X rather than a constant.
> 
>       BPF_STMT(BPF_MISC+BPF_COP, 0), /* A <- funcs[0](...) */
> 
>       typedef uint32_t(*bpf_copfunc_t)(struct mbuf *pkt,
>           uint32_t A, uint32_t *M);
> 
>       int bpf_set_cop(bpf_ctx_t *c, bpf_copfunc_t funcs[], size_t n);
> 
> The arguments passed to a called function would be the packet, accumulator
> and the memory store.  The return value would be stored in the accumulator
> and the register X would be reset to 0.  Note that the function may also
> change the memory store.  If the function index is out of range, then the
> register X would be set to 0xffffffff.

I like the idea but I have some questions:

1. Why do you need access to scratch memory? Is your goal to keep a
  state for C code between cop calls? In this case, you can use
  the standard void* pointer technique. You'd need to define special
  getter/setter cop functions and they will be slower than getting/setting
  scratch memory but it's more important to keep a very clear separation
  between C code and bpf code. You'd also need to pass void* to
  bpf_filter(9), of course.

2. Why do you set X to 0 and 0xffffffff? For the out-of-range access,
   all other bpf code aborts filter program with code 0. I think it's
   better to keep X unchanged.

3. Can cop "patch" itself or other cop functions at runtime? It'd be
   much safe if an array of cop functions was read-only. As an
   additional benefit when using bpfjit, you could generate direct calls
   for BPF_COP (but not for BPF_COPX) in bpfjit_generate_code().

Alex