[tptacek]

Write an eBPF program that actually needs to do any kind of meaningful string manipulation, and you'll quickly get a sense of just how rich the BPF helper inventory is in string processing functions. It'll be sharply obvious, because bounded loop enforcement will keep you from writing even the simplest string functions yourself.

[monocasa]

I never said that it's anywhere near a complete set. My point is that they exist as something that must be a helper because they represent a type of raw computation expected of bpf programs, but incompatible with it's verifier model.

The original parent was talking about removing all helpers,

> They show that various escape hatches can be eliminated or simplified. However they don't have a plan to eliminate all escape hatches

which simply doesn't make sense. The string helpers are a good example one might not have thought of beyond helpers that expose linux specific functionality.

The specific quantity of "quite a few" was left intentionally vague as it's orthogonal to my core point.

And yes, string ops are difficult if not impossible to write in verified bpf; that's almost a restatement of what I've been saying this whole thread.

[tptacek]

I don't think it's super common to do any kind of serious string manipulation in BPF. I happened to have Facebook's `dnswatch` open in my editor, and there are zero calls to strtol or printf. The idiomatic design here is to do that kind of thing in userland, piping raw stuff down a perf or ring buffer to postprocess in a "real" language runtime.

So my rebuttal would be: you could just remove those few string helpers, and not change much about the programming model.

[monocasa]

It's common enough in seccomp filters; I've personally used them there. Sometimes you trap into a user space dameon via seccomp_unotify to do relatively unbounded brain surgery on the unprivileged process, but that's pretty expensive to trap out and back to a daemon and it's much better if possible to make the decision in the filter program if you can get away with it.

Edit: Perhaps you'd be happy with another example that isn't a string processing function, but follows the same core idea I'm trying to get across of compute offload from the verified program to create useful verifiable programs: bpf_l3_csum_replace. It's not too hard to hit an mtu where you'd run out of instructions just recomputing the checksum because of the complexity of per byte computation required if it were to happen in regular bpf. This helper is not exposing a specific of the network stack or kernel really (other than who else needs one's complement?), but is instead really a unit of computation not super amenable to bpf verification that's still required of the use cases expected of bpf.