Unprivileged bpf()

Preventing information leakage is very difficult so it is better to start with a restrictive whitelist of allowed constructs than one can be reasonably sure are safe and gradually widen the set. It is much easier to implement such white-list in a higher level verifier precisely because it can distinguish a particular code pattern with much less efforts and O(N) complexity.

Otherwise I am afraid that a story of Java bytecode verification would repeat itself, albeit of a smaller scale. It took years for Sun to iron out bugs. Then it turned out that they could not do better then O(N**4) complexity in the worst case of the verification making DoS against a browser trivial. So they were forced to extend the bytecode format with extra information to simply the job for the verifier. That bloated already rather fat bytecode and introducing subtle compatibility bugs in quite a few applications.