Bounded loops in BPF programs [LWN.net]

Bounded loops in BPF programs

Posted Dec 6, 2018 0:53 UTC (Thu) by wahern (subscriber, #37304)
In reply to: Bounded loops in BPF programs by pctammela
Parent article: Bounded loops in BPF programs

Interestingly, in the transition from Lua 5.1 to Lua 5.2 the authors *removed* bytecode verification. This decision was made after several holes in the verifier were discovered. Because the VM relied on the verifier these holes were easily exploitable. The decision was made that time and attention would be better spent focusing on the VM and the compiler, but particularly on writing a VM that was intrinsically safe. The interplay between the VM, the verifier, and the compiler added unnecessary complexity and opacity. (IME such a decision is not simply a matter of moving invariant checks; without a verification step you tend to design things in a way less sensitive to malicious input.)

Not sure exactly how that relates to eBPF as the parallels aren't exact. eBPF is already bytecode, but because it's destined to be JIT-compiled it's similar to Lua script in terms of the pipeline. And unlike Lua where the VM and compiler are developed completely separately (except coordinated releases), in eBPF I presume the verifier and JIT compiler are more intimately bound.

Still, the rule of thumb in security engineering is that verification should be disfavored as it duplicates and disassociates logic in a way that increases the risk for bugs. It can be difficult to keep track of the places where the JITer and the runtime depend on the verifier. Even with a safe-by-design bytecode spec, bugs happen, and they're more likely when invariants are expressed thousands of lines apart than when they're expressed a few lines apart.

to post comments

Bounded loops in BPF programs

Posted Dec 6, 2018 12:30 UTC (Thu) by pctammela (guest, #126687) [Link]

> *removed* bytecode verification

Lua doesn't need a bytecode verifier if the interpreter exposed is already sandboxed by the developer, which was the real decision why the bytecode verifier was removed. Some people need it, some don't.

> Not sure exactly how that relates to eBPF as the parallels aren't exact.

Both are virtual machines running inside the operating system.

> Lua where the VM and compiler are developed completely separately

Lua has matured enough to be able to release new versions of both separately. It's just a matter of time to eBPF catch up to this pace.

This is also a design goal of Lua, allowing developers to tune/rewrite the VM without interfering with the compiler and maximizing portability of Lua scripts.

> Even with a safe-by-design bytecode spec, bugs happen, and they're more likely when invariants are expressed thousands of lines apart than when they're expressed a few lines apart.

Bugs happen because "Errare humanum est". The likeliness of bugs are intrinsically connected to software architecture and bugs can be minimized with a good test suite, which Lua has.

Lua is extremelly small, in fact the entire Lua language implementation (VM/Interpreter/C API) is just ~20k lines of logical C code, with the C API dominating a huge chunk of this. Last time I checked, this was smaller than (e)BPF itself. I don't understand your point here.