71–80 of 116 posts
I'm not happy about the entire concept of running user code in the kernel. As a special-purpose hack for servers that do very little else, maybe. As a standard OS feature, it seems to create too big an attack surface. One which has been exploited.[1] [1] https://www.theregister.com/2022/02/23/chinese_nsa_linux/
Earlier quoted context omitted.
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
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 ker…
Earlier quoted context omitted.
Unprivileged BPF is used for socket filters, for programs to BPF-extend themselves. It wasn't ever the case that unprivileged eBPF would allow you to, say, load a TC filter and read everybody's traffic.
Ok but you can like put a tracepoint on read/write and peek at what’s going through those, no?
Earlier quoted context omitted.
> eBPF code gets to read and, with many limits, write kernel memory Import kernel read/write functions into the Wasm module, so they can be policed. Or, if performance needs be, map limited portions of the kernel memory into the Wasm extensions linear memory. > programs terminate, Several Wasm runtimes count Wasm instructions (e.g. by internal bytecode rewriting) and dynamically enforce execution times. If static enf…
The BPF verifier doesn't simply count instructions (though there is a maximum instruction count as a failsafe). It can't: eBPF programs are JIT'd down to machine code --- that's part of what makes eBPF so attractive, because the code you're running is comparably fast to the "native" kernel code. Instead, it refuses to admit programs that can't be proven to constrain their loops.
I know this is a bit of an aside. The point still stands about the user not wanting their bpf program to terminate at runtime investment.
Earlier quoted context omitted.
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 ker…
This a link to string->integer conversion and comparison, and nothing else.
Earlier quoted context omitted.
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 ker…
This a link to string->integer conversion and comparison, and nothing else.
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.
Earlier quoted context omitted.
This a link to string->integer conversion and comparison, and nothing else.
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.