4 ms·
> In particular, limiting the number of Lua bytecode instructions is insufficient - even a single call to `string.find` can lock up the CPU [0]. At first glanc
by brmgb 6y ago
> In particular, limiting the number of Lua bytecode instructions is insufficient - even a single call to `string.find` can lock up the CPU [0].
At first glance, the second part of this sentence doesn't seem to support the initial premise. I am not too familiar with Lua bytecode but wouldn't "string.find" actually be compiled to multiple bytecode instructions ?
Unless a single bytecode instruction can lock up the cpu, doing so would most likely require either looping or recursive calls. Thus, by puting a hard limit on the number of instructions the sandbox can execute, it would end up aborting.
- lmm 6y ago> I am not too familiar with Lua bytecode but wouldn't "string.find" actually be compiled to multiple bytecode instructions ? It's probably a single opcode of "invoke native-code standard-library function/intrinsic".
- pansa2 6y agoYes. `string.find` is implemented in C. Invoking it (no matter how complex its arguments) requires just a few bytecode instructions.
- brmgb 6y agoWell, then that's library dependent and not an intrinsic part of the language. So shipping Lua safely would mean having to swap or drop parts of the standard library for something a bit more robust. Apparently, that's what Lunatik does so the work seems to already have been done.
- anonymoushn 6y agoAppending strings together is a single bytecode instruction and this cannot really be fixed.