eBPF vs verified Linux Kernel Modules

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](https://news.ycombinator.com/item?id=14726311) , 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](https://github.com/nyrahul/ebpf-guide/blob/master/docs/ebpf_vs_kernmod.rst) , 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](https://docs.kernel.org/trace/kprobes.html) and [tracepoints](https://docs.kernel.org/trace/tracepoints.html) . - [This page](https://github.com/nyrahul/ebpf-guide/blob/master/docs/ebpf_vs_kernmod.rst) 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".