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

41–49 of 49 posts

Re: Lua in the Kernel?

#41

Post by darek »

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)

Indeed, Teal looks like it has the right brains behind it (author was involved with several earlier attempts at typed Lua) and is actively maintained. I'm personally watching it for future game development usage.

Re: Lua in the Kernel?

#42

Post by smilliken »

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

This solution is problematic because there's no one time limit that makes sense across all past and present CPUs that span orders of magnitude of performance.. your lua script would always fail on some CPU and there wouldn't be a way to fix it.

Re: Lua in the Kernel?

#43

Post by dathinab »

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.

You could have a string.find C implementation which gets an additional budget parameter and depending on it might limit search or similar (and reports back how much "budged" was used)

Through always under the assumption that the C function is implemented correctly and adding need to do some explicit budged keeping makes it more complex and in turn more prone to errors.

Re: Lua in the Kernel?

#44

Post by htfy96 »

7373737373 wrote: post #11

It's only a matter of time until we have metered WebAssembly in the kernel :)

I guess running an alternative language in kernel is not very challenging. (I tried it two years ago and managed to run i8042 keyboard driver in WebAssembly on Qemu) The hard part is interoperability. Even in languages with automatic C header -> native prototypes conversion capabilities, many kernel features are still not properly handled, especially the macros. Status quo requires the user to manually extract wrappers which could be super tedious.

Re: Lua in the Kernel?

#45

Post by tinus_hn »

moring wrote: post #15
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.

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.

The problem only says you can’t tell if the programs stops without actually running it. But here you’re running it anyway.

Re: Lua in the Kernel?

#46

Post by gnufx »

What happened to the implementation of a Scheme interpreter in Linux from quite a while back? I can't immediately find a reference, and don't remember details. I vaguely remember there was something similar for SunOS too (in the '90s?).

Re: Lua in the Kernel?

#47

Post by mikevin »

DarkWiiPlayer wrote: post #31
coldtea wrote: post #24

Earlier quoted context omitted.

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

You could argue this doesn't really count as preventing though. It's preventing a symptom instead of the underlying problem.

Re: Lua in the Kernel?

#48

Post by gwd »

tinus_hn wrote: post #45
moring wrote: post #15

Earlier quoted context omitted.

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.

The problem only says you can’t tell if the programs stops without actually running it. But here you’re running it anyway.

If you run it and it stops, then it stops. If you run it and it runs forever, then it runs forever. But the point is that you want to know if it's going to run forever before you hit "forever".

Re: Lua in the Kernel?

#49

Post by anonymoushn »

brmgb wrote: post #28
pansa2 wrote: post #17

Earlier quoted context omitted.

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.

Appending strings together is a single bytecode instruction and this cannot really be fixed.
Post reply on HN