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