Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lua in the Kernel?

lwn.net

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Lua in the Kernel?

#31

Post by DarkWiiPlayer »

coldtea wrote: post #24
0x76 wrote: post #10

Earlier quoted context omitted.

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.

> You can't prevent infinite loops unless you've solved the halting problem right? Only in general arbitrary turing complete runtimes. For restricted subsets of instructions and specific implementations of runtimes you can. E.g. one could trivially disallow "jump" control flow, and limit loops to N iterations.

It's more simple than that: pull the plug on the entire turing machine. Lua runs in a VM, so you can stop it from the outside, which wouldn't be possible if the code was running directly in the CPU (Without an OS underneath it, that is).

Re: Lua in the Kernel?

#32

Post by DarkWiiPlayer »

donatj wrote: post #23

Smells like an attack vector waiting to happen to me. Malformed network request, sandbox escape, front page of Hacker News like 8-10 years from now? I am often irrationally paranoid about this sort of thing however.

The neat thing about Lua is: It's simple. It's reasonable to expect that a sandbox can be proven to be inescapable considering there's only a very limited set of features that would allow this sort of thing in the first place (mainly the `debug` library, which I doubt will be exposed)

Re: Lua in the Kernel?

#33

Post by cassepipe »

soapdog wrote: post #8
pansa2 wrote: post #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?

* 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)

There is also Luau and Ravi but I don't think any of them is official which was the original question

Re: Lua in the Kernel?

#34

Post by pctammela »

DarkWiiPlayer wrote: post #30
OskarS wrote: post #18

Earlier quoted context omitted.

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

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

ditto for eBPF when acessing the C helpers

Re: Lua in the Kernel?

#35

Post by vnogueira »

pansa2 wrote: post #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?

I believe he was talking about Pallene, which is being currently developed in LabLua

Paper: http://www.inf.puc-rio.br/~roberto/docs/pallene-sblp.pdf

Git Repo: https://github.com/pallene-lang/pallene

Re: Lua in the Kernel?

#36

Post by fsfod »

d33 wrote: post #7
moonchild wrote: post #3

Freebsd 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.

Grub also has an optional module run to Lua code https://git.savannah.nongnu.org/cgit/grub-extras.git/tree/lu...

Re: Lua in the Kernel?

#37

Post by kevans91 »

d33 wrote: post #7
moonchild wrote: post #3

Freebsd 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.

Note that we haven't yet introduced .lua configuration capabilities (that's a project branch off to the side), but it does certainly make modifying menu entries and other fun stuff a lot more palatable in my experience.

Re: Lua in the Kernel?

#39

Post by magicalhippo »

ivzhh wrote: post #38

ZFS compiles a modified version Lua 5.2 into zfs.ko and loaded into Linux kernel.

To expand slightly, it's used for "channel programs", scripts that can interact with ZFS to create or modify datasets and similar tasks. There's a write-up here[1] about the feature.

Main advantage is that it allows for multiple operations to be applied atomically, as well as better error handling.

[1]: https://www.delphix.com/blog/delphix-engineering/zfs-channel...

Re: Lua in the Kernel?

#40

Post by lioeters »

raverbashing wrote: post #21
WalterGR wrote: post #12

Earlier quoted context omitted.

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.”

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

Post reply on HN