3 ms·

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

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 3y ago
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 https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
- monocasa 3y ago
  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/helpers.c#L439 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 3y ago
    This a link to string->integer conversion and comparison, and nothing else.
    - monocasa 3y ago
      So "generic string processing helpers" provided by the kernel?
      - insanitybit 3y ago
        "quite a few" tho
        monocasa 3y ago
        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.
        tptacek 3y ago
        Rookie mistake! :P
    - ongy 3y ago
      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 3y ago
        That's all that's there. String-integer conversion and comparison.
        bandrami 3y ago
        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"

tptacek 3y ago

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 https://man7.org/linux/man-pages/man7/bpf-helpers.7.html

monocasa 3y ago
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/helpers.c#L439 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 3y ago
  This a link to string->integer conversion and comparison, and nothing else.
  - monocasa 3y ago
    So "generic string processing helpers" provided by the kernel?
    - insanitybit 3y ago
      "quite a few" tho
      - monocasa 3y ago
        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.
        tptacek 3y ago
        Rookie mistake! :P
  - ongy 3y ago
    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 3y ago
      That's all that's there. String-integer conversion and comparison.
      - bandrami 3y ago
        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"