lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]





----- Ursprüngliche Message -----
> Von: David Heiko Kolf <kolf@gmx.de>
> An: Lua mailing list <lua-l@lists.lua.org>
> CC: 
> Gesendet: 10:24 Freitag, 29.März 2013
> Betreff: Re: Lua and preemptive scheduling for coroutines
> 
> Josh Simmons wrote:
>>>  - Code may loop forever, especially a 3rd party untrusted code, which 
> you may want to run by loading scripts
>>  You cannot stop this from Lua (without removing _all_ C functions from
>>  the sandbox), you need to use threading or processes at the OS level
>>  to limit access to resources.
> 
> I guess it is not too hard to review the C functions from the integrated
> libraries for this.  Besides the functions you obviously wouldn't put in
> a sandbox (file access, debug functions, etc.) the pattern matching and
> string repetition come to my mind as being potentially dangerous for
> consuming lots of time or memory without triggering Lua hooks.
> 
> An alternative to using Lua hooks might be to copy the Lua parser into
> an own library and patch it to include a call to yield at the end of any
> loop (and in Lua 5.2 for any goto that jumps backwards).  The debug
> hooks might be more efficient for small loops with high repetition
> counts though.

This is interesting, David! This would be the exact equivalent of a byte-code instrumentation approach for Java, which I mentioned before,  which would inject conditional yields. 
Any idea how difficult would it be to put the Lua parser into an own library? Would it mean building my own Lua binaries by substituting standard parser by the patched one? Do I need to include calls at the syntactic level or in the internal representation (e.g. abstract syntax tree, bytecodes or whatever is used by Lua)? Would it also work for LuaJIT? Or should I patch both?

-Leo