Re: [patch] changing lua_Number to int64_t

[Marc Balmer <marc%msys.ch@localhost>]

Am 17.11.13 06:30, schrieb Terry Moore:
>> From: Lourival Vieira Neto [mailto:lourival.neto%gmail.com@localhost]
>>> Watch out, by the way, for compiled scripts; I have not checked Lua 5.x,
> but
>>> you may find if not careful that the compiled binary is not loadable on
>>> machines with different choices for LP64, ILP32, etc. This is somewhat
>>> independent of the choice of lua_Number mapping.
>>
>> Yes, Lua bytecode isn't portable in fact. BTW, loading Lua bytecode is
>> not recommended by Lua team. It isn't safe.
> 
> It's not *much* less safe than compiling and executing a string in the
> kernel. The only additional attack surfaces are that you can write things
> that the compiler wouldn't write. This can (1) cause a crash at load time,
> or it can (2) cause surprising behavior later. 

The problem is that malicious bytecode in 5.1 is possible.  That is why
there is a guad against loading bytecode.

> I suspect that anyone who would want to allow Lua in the kernel would be
> somewhat indifferent to type-2 safety issues.

Only if loading precompiled chunks, which btw needs a custom version of
luac.  You can not compile bytecode for in-kernel use using the standard
luac(1) program.


If you don't trust the input
> string, you had better not give it to the kernel (whether or not it's
> compiled). Type-1 safety issues ought to be fixed, as careful examination of
> the input data only slows down the load process -- it has no run-time
> effects. 
> 
> Given that Lua byte codes can be translated into C arrays and then loaded
> via the API, portability issues can creep in through the back door. 
> 
> Best regards,
> --Terry
>