3 ms·
First, there's no need to do this "on demand." You can ship a .o around and load it with bpftool. My team does a version of this at Facebook (using libbpf direc
by alexgartrell 7y ago
First, there's no need to do this "on demand." You can ship a .o around and load it with bpftool. My team does a version of this at Facebook (using libbpf directly) and it works really well. The big use case for on-demand programming is in tracing where you want to capture structs, but BTF and Compile-once, run-everywhere will mitigate this need [0]
Second, I don't actually agree. JIT compilation is a generally accepted approach -- who cares what the IR is? And the bpf runtime is ULTRA constrained, so you can't slip a `system("rm -rf /")` in there (by a long shot).
[0] https://www.kernel.org/doc/html/latest/bpf/btf.html https://www.kernel.org/doc/html/latest/bpf/btf.html
- jdc 7y agoI'm thoroughly skeptical that general acceptance means that JIT compilation doesn't increase the attack surface of the stack.
- Dylan16807 7y agoYou'd need an interpreter at least, to avoid some kind of hideously complex system. So it's a question of interpreter vs. JIT, and a JIT makes it more feasible to use an ultra-simple language with aggressive verification, without losing too much speed. Every feature has an attack surface, but you have to compare against the alternative, not the lack of feature. (This assumes that you can't force it to use a kernel interpreter despite the JIT existing. Otherwise perhaps that is the part that should be disabled.)
- ignoramous 7y agoTangential: Does your team publish papers or write blog posts on the kind of engineering or research it does? I'd like to read it, or at least add it to my queue. Thanks.
- jauer 7y agoThere was a recent talk on tupperware that gets into some of what Alex's team does: https://engineering.fb.com/data-center-engineering/tupperware/ https://engineering.fb.com/data-center-engineering/tupperwar...
- ignoramous 7y agoThat was interesting. Thanks.