Re: [patch] changing lua_Number to int64_t

[Lourival Vieira Neto <lourival.neto%gmail.com@localhost>]

On Sun, Nov 17, 2013 at 3:30 AM, Terry Moore <tmm%mcci.com@localhost> wrote:
>> 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.
>
> I suspect that anyone who would want to allow Lua in the kernel would be
> somewhat indifferent to type-2 safety issues. 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


Sorry. I think I didn't make myself clear here. By 'it isn't safe' I
meant that loading bytecode is not _reliable_, unless you have
compiled it in the same Lua build that you are using to run.
Otherwise, It can lead to malfunctioning both in kernel or user space.
I was not referring myself to possible attacks. Note, that this is not
all about portability among platforms, bytecode is not portable among
different builds of Lua interpreter. In fact, Lua interpreter has no
compromise with bytecode exchanging; the authors' idea is to
distribute Lua source code instead of bytecode (AFAIK). I support that
is not a good idea to compile a Lua script in some Lua interpreter
build and then run it on another one (even on the same platform).
Moreover, there is no significative difference in the time cost to
load strings or byte codes. Lua compiling time is really fast (even
comparing to the loading time of byte code).

Regards,
-- 
Lourival Vieira Neto