In what way is eBPF superior to a kernel module verified on the user-side?
I'm not disputing the value of verified code; both approaches would be fully statically verified.Both approaches require capabilities usually only given to privileged users.
However, running the verifier in user-space gives the user more choices between verifiers, safety-levels, and permissible assumptions. The verifier can also be more rapidly developed separately from the kernel.
Things I read before asking this question:
I found this hackernews thread, which only says that some limited eBPF filters do not need privilege, but I understand most eBPF applications still will require privilege?
I found this page, which claims
Kernel modules have a specific entry point (init_module()) and exit (cleanup_module()) point. eBPF can be hooked to any kprobe/kretprobe/tracepoint and thus can be used for tracing
Contrary to the previous quote, it seems kprobe/kretprobe/tracepoints can be hooked (aka registered) from loadable kernel modules according to Linux documentation on kprobes/kretprobes and tracepoints.
This page also claims that eBPF cannot be pre-empted and kernel modules can. Whenever I Google anything about the Linux kernel preempting module code, they always talk about pre-emptying user-space never kernel-space. I don't know what it means that the "Kernel module follows regular kernel code preemption logic" but on the other hand "eBPF instruction-set execution cannot be preempted by kernel".