[monocasa]

The escape hatches are unfortunately core to how eBPF in the kernel can work at the moment. It keeps the kernel from having to provide every possible piece of data the program might need as an argument, and provides a lot of assists that otherwise wouldn't be verifiable in general code. Stuff like string operations that would cut into the max 4096 instruction count.

[tptacek]

For the most part, the kernel doesn't provide generic string processing helpers. Most helpers are there to form the basis for specific eBPF integration points (the majority are packet and socket handling tools).

https://man7.org/linux/man-pages/man7/bpf-helpers.7.html

[monocasa]

The kernel provides quite a few string processing helpers; I'm not sure why they're not documented. Perhaps the purpose of the document is to highlight bpf specific functionality rather than underlying runtime helpers?

You can see them listed here: https://elixir.bootlin.com/linux/latest/source/kernel/bpf/he...

And my point in highlighting them in this discussion was to get one to consider how of trap outs to the kernel are sort of fundamental. You get 4096 instructions to execute before you're cut off by the kernel (albeit statically). Given that, say, PATH_MAX is 32768, then you simply don't have enough compute time available to process certain strings you'd expect some bpf filters to be able to handle.

So basically I just wanted to hit home that some raw computation expected of bpf is incompatible with it's current verification model and at the very least extremely deep changes to bpf would need to occur to get rid of helpers.

[tptacek]

This a link to string->integer conversion and comparison, and nothing else.

[ongy]

that's what GP said.

They are semantically simple string operations whose computational complexity scales with string length. Near unbound string lengths would exhaust the time (somewhat aproximated by instruction) budget of eBPF applications doing even a single one.

[tptacek]

That's all that's there. String-integer conversion and comparison.

[bandrami]

I think the point was not to show "there are a lot of helper functions" but rather to point out "the (undocumented) helper functions that exist are problematic"

[monocasa]

So "generic string processing helpers" provided by the kernel?

[insanitybit]

"quite a few" tho

[monocasa]

There are others listed in the thread. The specific quantity of 'quite a few' is orthogonal to the core point and was intentionally left vague in what now appears to be a misguided attempt to keep the comment concise and focused.