4 ms·

I don't really follow the development of Lua in any way. Lua 5.3 was very underwhelming to me, I didn't care for the ints and bit operators at all (and before

by FRex 9y ago

I don't really follow the development of Lua in any way. Lua 5.3 was very underwhelming to me, I didn't care for the ints and bit operators at all (and before 5.3 the one number type was a selling point) and it's annoying how there is such a clear strong split between 5.3 and LuaJIT because it effectively finalized the fork that 5.2 has sort of started. Some things (like Love2D, OpenResty and other performance conscious stuff) stuck with LuaJIT so basically a 5.1 on steroids with few 5.2 features. 5.1 also had the killer feature of incremental GC and came at a nice time and was the main Lua for almost 6 years so it stuck into gamedev a lot (which is where I picked Lua from, my hobbist gamedeving). I also stick to 5.1 by default in my hobby gamedev to be able to bring in LuaJIT at any time and ignore 5.2 and 5.3 pretty much. My thesis was about history of Lua a bit (rehashing what's on the main website plus few Roberto's articles pretty much) and then a lot about how stock Lua 5.1 is implemented (most of it is 1:1 transferable to other stock Luas) like how bytecode is executed, how does GC work, what does it mean Lua is register VM and not stack one, how are internal structures laid out, how functions and closures and threads work, etc. It's (official) English title was "Analysis of code of original implementation of Lua 5.1" but it is written in Polish ("Analiza kodu oryginalnej implementacji jezyka Lua 5.1"). I don't think it's available anywhere. That was my engineering (inżynier) thesis which I defended in February and I'm now doing a master thesis but it's purely mathematical CS stuff and not related to Lua at all.

marktangotango 9y ago
As an aside, there’s stuff on the lua wiki about sandboxing lua, how would you go about sandboxing lua to limit heap, cpu cycles, and os level api calls? For lua 5.1? For luajit? An example use case would be letting users upload scripts to run in game?
- FRex 9y ago
  I never did that actually and it seems involved, hard and very limiting for what such a script could do. I dislike talking about touchy high risk stuff like that in general since someone might think what I say is a list of things to do to be 100% secure and get burned. What it says on [0] is a good start I guess: only textual code input, no bytecode (5.1 has bytecode verification but it was removed in 5.2 because it had flaws and gave false sense of security, there were examples of breaking stuff up with malicious handcrafted bytecode), white listing. To not allow something (like os or debug libs) to be used just don't include it in the environment for that used supplied function (it does restrict you quite a bit though I guess...). For memory you could use your own allocator and enforce a limit there (and probably set your own atpanic function in 5.1 and longjmp out of it because you might kill the entire program with the default one when Lua won't be able to alloc the error message itself, in 5.2 and 5.3 it's preallocated in the VM so that won't happen). To prevent runaway Lua loops you can use the count debug hook and throw a Lua error in it, pcall will get that (just remember to reset it between calls because it doesn't reset to 0 on its own). Preventing runaway C loops is up to making sure you don't expose something that can get stuck. You could also set count to something low or use line debug hook and check the time in it and error out if the code took too long already but it might slow the code down too badly (depends on what you do I guess). That stuff (mem alloc, debug hooks, panic, environments, etc.) is in the docs. Long strings can also DoS the hashing algorithm and that might totally kill performance with tables, it's a trivial change to fix that yourself or use one of the patches[1]. It came up on the mailing list too. I'm sure it happens on 5.1, not sure about latest 5.2 and 5.3 right now and I don't have time to look into it. LuaJIT doesn't also let you set the allocator on 64 bit and has some other issues with out of memory errors[2] (I don't know what they are exactly about). I guess it's out of the question if you're really paranoid (stock Lua 5.1 is also way easier to read, modify and compile IMO). I'm not very familiar with LuaJIT. [0] - http://lua-users.org/wiki/SandBoxes http://lua-users.org/wiki/SandBoxes [1] - http://lua-users.org/wiki/HashDos http://lua-users.org/wiki/HashDos [2] - http://luajit.org/status.html http://luajit.org/status.html

by FRex 9y ago

marktangotango 9y ago

As an aside, there’s stuff on the lua wiki about sandboxing lua, how would you go about sandboxing lua to limit heap, cpu cycles, and os level api calls? For lua 5.1? For luajit? An example use case would be letting users upload scripts to run in game?

FRex 9y ago
I never did that actually and it seems involved, hard and very limiting for what such a script could do. I dislike talking about touchy high risk stuff like that in general since someone might think what I say is a list of things to do to be 100% secure and get burned. What it says on [0] is a good start I guess: only textual code input, no bytecode (5.1 has bytecode verification but it was removed in 5.2 because it had flaws and gave false sense of security, there were examples of breaking stuff up with malicious handcrafted bytecode), white listing. To not allow something (like os or debug libs) to be used just don't include it in the environment for that used supplied function (it does restrict you quite a bit though I guess...). For memory you could use your own allocator and enforce a limit there (and probably set your own atpanic function in 5.1 and longjmp out of it because you might kill the entire program with the default one when Lua won't be able to alloc the error message itself, in 5.2 and 5.3 it's preallocated in the VM so that won't happen). To prevent runaway Lua loops you can use the count debug hook and throw a Lua error in it, pcall will get that (just remember to reset it between calls because it doesn't reset to 0 on its own). Preventing runaway C loops is up to making sure you don't expose something that can get stuck. You could also set count to something low or use line debug hook and check the time in it and error out if the code took too long already but it might slow the code down too badly (depends on what you do I guess). That stuff (mem alloc, debug hooks, panic, environments, etc.) is in the docs. Long strings can also DoS the hashing algorithm and that might totally kill performance with tables, it's a trivial change to fix that yourself or use one of the patches[1]. It came up on the mailing list too. I'm sure it happens on 5.1, not sure about latest 5.2 and 5.3 right now and I don't have time to look into it. LuaJIT doesn't also let you set the allocator on 64 bit and has some other issues with out of memory errors[2] (I don't know what they are exactly about). I guess it's out of the question if you're really paranoid (stock Lua 5.1 is also way easier to read, modify and compile IMO). I'm not very familiar with LuaJIT. [0] - http://lua-users.org/wiki/SandBoxes http://lua-users.org/wiki/SandBoxes [1] - http://lua-users.org/wiki/HashDos http://lua-users.org/wiki/HashDos [2] - http://luajit.org/status.html http://luajit.org/status.html