Lua in the Kernel?
lwn.net
Lua in the Kernel?
1–10 of 49 posts
Re: Lua in the Kernel?
#2NetBSD supports Lua in the kernel since 2012.
https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2...
Re: Lua in the Kernel?
#3Freebsd has used lua in its bootloader for a few years now.
https://wiki.freebsd.org/SummerOfCode2014/LuaLoader
https://lists.freebsd.org/pipermail/freebsd-current/2018-Feb...
Re: Lua in the Kernel?
#4NetBSD supports Lua in the kernel since 2012. https://www.netbsd.org/gallery/presentations/mbalmer/fosdem2...
It's in fact exactly the same thing, since NetBSD Lua started as a port of Lunatik, which is the topic of this article.
Re: Lua in the Kernel?
#5> 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 be surprised if it could prevent a script from running indefinitely. In particular, limiting the number of Lua bytecode instructions is insufficient - even a single call to `string.find` can lock up the CPU [0].
> They are using the standard Lua, rather than the LuaJIT fork, Neto said, in answer to another question.
Using LuaJIT would make sandboxing significantly more difficult, because it's much more complex than regular Lua and hence more likely to have exploitable bugs. This is the reason that game consoles disallow JIT-compilation - and hence games tend to use regular Lua rather than LuaJIT.
Re: Lua in the Kernel?
#6> Investigation of a "typed Lua" for compilation is something on the roadmap. That is the approach that the main Lua project is taking to compete with LuaJIT on performance.
I haven't heard anything about an official "typed Lua". Is there information about it somewhere?
Re: Lua in the Kernel?
#7Freebsd has used lua in its bootloader for a few years now. https://wiki.freebsd.org/SummerOfCode2014/LuaLoader https://lists.freebsd.org/pipermail/freebsd-current/2018-Feb...
Wow, it actually sounds like a very elegant idea. I always viewed GRUB as overly complex and rather unpleasant to configure. I wonder why they hadn't gone this way.
Re: Lua in the Kernel?
#8> Investigation of a "typed Lua" for compilation is something on the roadmap. That is the approach that the main Lua project is taking to compete with LuaJIT on performance. I haven't heard anything about an official "typed Lua". Is there information about it somewhere?
* Typed Lua: https://github.com/andremm/typedlua (not actively maintained)
* tl: https://github.com/teal-language/tl a compiler for Teal a typed dialect of lua. (actively maintained)
Re: Lua in the Kernel?
#9> 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, 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.
Re: Lua in the Kernel?
#10> 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.