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

21–30 of 49 posts

Re: Lua in the Kernel?

#21

Post by raverbashing »

WalterGR wrote: post #12
pansa2 wrote: post #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 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.”

Just add a time limit to the sandbox as well

Re: Lua in the Kernel?

#22

Post by pansa2 »

0x76 wrote: post #10
pansa2 wrote: post #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 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.

> They could of course just limit the run time

It seems as though this would be more robust than limiting the number of bytecode instructions. I wonder if that’s true and if so, why it’s not more commonly recommended.

Re: Lua in the Kernel?

#23

Post by donatj »

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.

Re: Lua in the Kernel?

#24

Post by coldtea »

0x76 wrote: post #10
pansa2 wrote: post #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 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.

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

Re: Lua in the Kernel?

#25

Post by Benjamin_Dobell »

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?

Shameless self promotion: https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis

Re: Lua in the Kernel?

#26

Post by 7373737373 »

moring wrote: post #16
7373737373 wrote: post #11

It'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.

Yeah, my comment is actually unironic :)

There are a few ways to limit the execution time of wasm programs:

- inject code after a set of instructions with a certain duration and in each loop that calls an external function which meters and destroys/suspends execution when a limit is reached (e.g. https://github.com/ewasm/wasm-metering)

- use a VM which counts instructions (e.g. https://github.com/perlin-network/life)

- use hardware interrupts

More random thoughts: https://esolangs.org/wiki/RarVM

Re: Lua in the Kernel?

#27

Post by [deleted] »

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?

[deleted]

Re: Lua in the Kernel?

#28

Post by brmgb »

pansa2 wrote: post #17
lmm wrote: post #14

Earlier quoted context omitted.

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

Well, 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.

Re: Lua in the Kernel?

#29

Post by DarkWiiPlayer »

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

> This is the reason that game consoles disallow JIT-compilation - and hence games tend to use regular Lua rather than LuaJIT.

You can disable the JIT in LuaJIT and still get better performance because it's a different implementation of the VM.

> but I'd be surprised if it could prevent a script from running indefinitely.

You'd have to patch the standard library a bit to avid things like `string.find` causing trouble, but as far as core Lua features go, yes, you can do that and all you need is to install a debug hook (Preferably from C, because performance, but you can even do this 100% from within Lua)

-----

EDIT: Here's some benchmarks I did for this a while ago https://gist.github.com/DarkWiiPlayer/f639a38df53e39df63497c...

Re: Lua in the Kernel?

#30

Post by DarkWiiPlayer »

OskarS wrote: post #18
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.”

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.
Post reply on HN