You can, it just won't be validated as the CFG read by the kernel has to be a DAG. But the compiler has no problems emitting code with arbitrary loops. cBPF is different; branch offsets are unsigned there.

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).

> You can, it just won't be validated as the CFG read by the kernel has to be a DAG.

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.

No, but you can write your own eBPF VM that doesn’t have the same restrictions.

Do you have a link to the document?

I never heard of that one can write a new eBPF VM.

What do you mean? The source is all open, and the bytecode format is well documented. There's nothing stopping anyone from writing their own with different semantics.

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

I was saying a eBPF vm running inside the kernel.

A userspace VM that do not have the same capability as the kernel one is not useful when tracing kernel internals.

You can patch your kernel, or write your own vm. BPF is ultimately just a kernel module under Linux. My vm runs in kernel space just fine as well (but is built on something that looks more like sel4 rather than Linux on the inside).

If you provided enough of std, or ported that VM to no_std that rust vm would work just fine in the kernel too.

This is an interesting option.

Although in our case, our eBPF runs in external customer's environment, and we cannot ask them to patch their kernels with our code.

I feel like we're talking on two different levels here.

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.

Also different time scale.

I am on existing stuff can be readily used. You are probably estimating the future, I guess?

One similarity seems to be the way they both restrict user access to the stack to prevent stack corruption or overflow. The article talks about how eBPF doesn't have an explicit stack pointer and doesn't give a function access to caller or callee stack frames. I have read similar things about how WASM protects its stack, though I don't know much of the details.

I mean, their runtime models might share similarities but eBPF is not meant to be a general purpose machine, it is kinda a kernel add-on for programmable tracing.

>it is kinda a kernel add-on for programmable tracing.

Well, that's the thing I personally mostly use it for via bpftrace and bcc, but that's not the only thing. It's being used for a lot of networking related things too. XDP, CloudFlare uses it for a lot of their DDoS mitigation, etc.

There is ongoing to work to allow support for counted looping (including a working patchset that is under review) but in general it's true that an eBPF program does not allow a given segment of code to have multiple entry points (a generalization of the prior rule that jumps may only jump forward in the instruction stream).

For loops are now allowed with eBPF in the latest kernels

Provably bounded loops, I’d assume?

Loops are supported in newer kernels as long as they have an upper bound which can be constant, or unknown but bounded value.