It's only a matter of time until we have metered WebAssembly in the kernel :)
Lua in the Kernel?
11–20 of 49 posts
Re: Lua in the Kernel?
#12> Scripts should not be able to crash the system, run indefinitely, or corrupt other parts of the system. To ensure that, Lunatik uses the Lua VM facilities for sandboxing the scripts so that they run in a safe execution environment [...] the number of instructions can be limited, so that infinite loops are not possible. Lua's sandbox should be able to prevent scripts from crashing or corrupting the system, but I'd b…
I'd be surprised if it could prevent a script from running indefinitely. In particular, limiting the number of Lua bytecode instructions is insufficient
FTA: “Lua has a facility to interrupt a script after it has run a certain number of instructions.”
Re: Lua in the Kernel?
#13> Scripts should not be able to crash the system, run indefinitely, or corrupt other parts of the system. To ensure that, Lunatik uses the Lua VM facilities for sandboxing the scripts so that they run in a safe execution environment [...] the number of instructions can be limited, so that infinite loops are not possible. Lua's sandbox should be able to prevent scripts from crashing or corrupting the system, but I'd b…
You can't prevent infinite loops unless you've solved the halting problem right? They could of course just limit the run time if they really wanted to make sure scripts don't run indefinitely.
ePBF prevents infinite loops by restricting the language:
Re: Lua in the Kernel?
#14> Scripts should not be able to crash the system, run indefinitely, or corrupt other parts of the system. To ensure that, Lunatik uses the Lua VM facilities for sandboxing the scripts so that they run in a safe execution environment [...] the number of instructions can be limited, so that infinite loops are not possible. Lua's sandbox should be able to prevent scripts from crashing or corrupting the system, but I'd b…
> 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…
> 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".
Re: Lua in the Kernel?
#15> Scripts should not be able to crash the system, run indefinitely, or corrupt other parts of the system. To ensure that, Lunatik uses the Lua VM facilities for sandboxing the scripts so that they run in a safe execution environment [...] the number of instructions can be limited, so that infinite loops are not possible. Lua's sandbox should be able to prevent scripts from crashing or corrupting the system, but I'd b…
You can't prevent infinite loops unless you've solved the halting problem right? They could of course just limit the run time if they really wanted to make sure scripts don't run indefinitely.
The halting problem only says that you cannot tell if a program ever stops, i.e. takes a finite number of steps but without any a priori bounds. If you limit the number of steps to N, you can just run N steps of the program on your given input and look if it has stopped already.
Re: Lua in the Kernel?
#16It's only a matter of time until we have metered WebAssembly in the kernel :)
Actually, why not? The main reason that "in the kernel" is concerning is because untrusted code needs some kind of sandboxing, either by static analysis or by run-time checks. (Most modern systems do a combination of both).
After all, the whole "in the kernel" vs. "in userland" distinction only exists because we get hardware-accelerated sandboxing from the CPU and OS combined.
Re: Lua in the Kernel?
#17Earlier quoted context omitted.
> 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…
> 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".
Yes. `string.find` is implemented in C. Invoking it (no matter how complex its arguments) requires just a few bytecode instructions.
Re: Lua in the Kernel?
#18> Scripts should not be able to crash the system, run indefinitely, or corrupt other parts of the system. To ensure that, Lunatik uses the Lua VM facilities for sandboxing the scripts so that they run in a safe execution environment [...] the number of instructions can be limited, so that infinite loops are not possible. Lua's sandbox should be able to prevent scripts from crashing or corrupting the system, but I'd b…
I'd be surprised if it could prevent a script from running indefinitely. In particular, limiting the number of Lua bytecode instructions is insufficient FTA: “Lua has a facility to interrupt a script after it has run a certain number of instructions.”
string.find is implemented in C, not Lua. As far as Lua is concerned, that call is a single instruction.
Re: Lua in the Kernel?
#19It's only a matter of time until we have metered WebAssembly in the kernel :)
We all know the Linux kernel needs a more "engaging" UX . . .
Re: Lua in the Kernel?
#20> Scripts should not be able to crash the system, run indefinitely, or corrupt other parts of the system. To ensure that, Lunatik uses the Lua VM facilities for sandboxing the scripts so that they run in a safe execution environment [...] the number of instructions can be limited, so that infinite loops are not possible. Lua's sandbox should be able to prevent scripts from crashing or corrupting the system, but I'd b…
You can't prevent infinite loops unless you've solved the halting problem right? They could of course just limit the run time if they really wanted to make sure scripts don't run indefinitely.
[deleted]