Christoph Badura wrote:
> On Tue, Oct 22, 2013 at 09:25:19AM +0100, Alexander Nasonov wrote:
> > We just need to make sure that all entry points to Lua are protected and
> > hope that the above panic will never trigger.
>
> Actually, I would prefer if that call to panic wasn't there at all.
> Instead the script/state should be aborted noisily.
I have a simple code you can play with in userspace.
#include
#include
const char prog[] =
"print'hi'\n"
"error'throw'\n"
"print'dead code'\n";
int main()
{
lua_State *L;
L = luaL_newstate();
luaL_openlibs(L);
if (luaL_loadstring(L, prog) == 0) {
// Dangerous:
lua_call(L, 0, 0); // no args and no return values
// Protected call should be safe:
//lua_pcall(L, 0, 0, 0);
}
lua_close(L);
return 0;
}
If you link it with vanilla Lua, you'll get
$ gcc -I/usr/pkg/include/lua-5.1/ -O -g lua-throw.c -L/usr/pkg/lib
-Wl,-rpath,/usr/pkg/lib -llua5.1
$ ./a.out
hi
PANIC: unprotected error in call to Lua API ([string "print'hi'..."]:2: throw)
If you comment out exit(EXIT_FAILURE) in luaD_throw(), you'll get a
crash because Lua will try to execute the third line while its state
is inconsistent:
$ gcc -I/usr/pkg/include/lua-5.1/ -O -g lua-throw.c -L `pwd`/lua-5.1.5/src/
-llua -lm
$ gdb ./a.out
(gdb) run
Starting program: /home/alnsn/src/test/a.out
hi
PANIC: unprotected error in call to Lua API ([string "print'hi'..."]:2: throw)
Program received signal SIGSEGV, Segmentation fault.
0xb7d8 in luaD_precall ()
(gdb) bt
#0 0xb7d8 in luaD_precall ()
#1 0x00011084 in luaV_execute ()
#2 0x in ?? ()
You really need this panic or KASSERT even if you make sure all your
scripts are properly isolated. You can achieve these in two ways:
1. Set a panic handler with lua_atpanic() which jumps to your safety
point (if your handler returns, the control is passed to the line
in question).
2. Make sure that all scripts are executed using lua_pcall. For
instance, code that loads kmods written in Lua can do this
seamlessly.
While I agree that it's good to have a protection from fool scripts, but
being able to control loading of scripts manually have advantages too.
The link below is a skeleton for bpfjit generator. It doesn't yet
generate a real code but it creates a Lua array of instructions, passes
it from C to Lua, creates sljit compiler object and gerenates a simple
function inside Lua script, then returns that object to C where it's
casted to C object. If you look at interface, you won't see Lua at all,
it's hidden from public.
https://github.com/alnsn/luaSljit/blob/master/examples/bpfjit/bpfjit.c
Alex
