string.find is implemented in C, not Lua. As far as Lua is concerned, that call is a single instruction.

You could have a string.find C implementation which gets an additional budget parameter and depending on it might limit search or similar (and reports back how much "budged" was used)

Through always under the assumption that the C function is implemented correctly and adding need to do some explicit budged keeping makes it more complex and in turn more prone to errors.

A single instruction that can run for a long time. That's the point.

ditto for eBPF when acessing the C helpers

Just add a time limit to the sandbox as well

Apparently, the sandbox cannot enforce such a time limit.

From a similar thread to the one linked from the root comment:

> ..Attempts to control untrusted scripts may be in vain. E.g. string.find, string.rep and other C functions can be abused and will either run forever or allocate unlimited amounts of memory. This is true for both Lua and LuaJIT.

> The only reasonably safe way to handle untrusted Lua scripts is to isolate them in a process context and to make use of per-process quotas/limits provided by the operating system.

Improved functions sandboxing in Lua and LuaJIT - http://lua-users.org/lists/lua-l/2011-02/msg01106.html

This solution is problematic because there's no one time limit that makes sense across all past and present CPUs that span orders of magnitude of performance.. your lua script would always fail on some CPU and there wouldn't be a way to fix it.