Are you saying the kernel bpf verifier can be disabled when loading a probe? AFAIK, there is no such option.
TBH, I cannot understand this statement. I've written a few thousands of lines of BCC C code as eBPF. Never encounter any reference to actually have loops in the code.
I never heard of that one can write a new eBPF VM.
There's no doc on my work as it's private jerk offy personal project that I work on when I get tired of jira tasks and process.
Edit: here's an example of one someone did in rust https://github.com/qmonnet/rbpf
A userspace VM that do not have the same capability as the kernel one is not useful when tracing kernel internals.
If you provided enough of std, or ported that VM to no_std that rust vm would work just fine in the kernel too.
Although in our case, our eBPF runs in external customer's environment, and we cannot ask them to patch their kernels with our code.
It's sort of like how Oak was this neat virtual machine for running on a early 90s PDA prototype. Then the writers of that VM realized that they had written a really general purpose VM, cleaned it up and released the first Java.
This general of a VM (talking about eBPF now) hasn't been a first class citizen of a mainstream kernel before. The devs are taking a very cautious approach (as they should), but ultimately eBPF is way bigger than a tracing tool. I wouldn't be surprised to see nearly everything you currently do with a kernel module ultimately being allowed by eBPF too. Maybe more like emulating other OS's kernels as easily as you'd start another container.
I am on existing stuff can be readily used. You are probably estimating the future, I guess?
I'm working on an exokernel built around a eBPF VM that'll let you use loops in certain circumstances (ie. more or less regular threads that happen to be in kernel space and are preemptible).