Re: Reducing Lua's Trusted Computing Base

[Luiz Henrique de Figueiredo <lhf@...>]

> The only shortcoming I see is that Lua's VM was not designed to run malicious code.

That's is a feature! Perhaps you mean that the VM is not designed to
deal with malicious bytecode. It's not, for several reasons: one is
that the halting problem is unsolvable; another is that such checks
would slow down the VM.

Until 5.1, Lua included a bytecode verifier that had several flaws that
became increasingly difficult to fix. So, it was dropped in 5.2. The
internal compiler is quite fast that all Lua programs can be compiled
at load time with no really noticeable penalty.

> For example, what happens when a "malicious" chunk specifies an invalid
> opcode? Does the VM halt or just ignore it?

Bytecode generated by the internal compiler does not include invalid
opcodes.
 
> Therefore, when I want to sandbox code using Lua, I must trust not only the
> VM but also the "compiler" (lexer, parser,etc). There's a lot of extra C
> code outside the VM that also needs to be trusted.

I'm not sure I follow. Any problem in the internal compiler is a bug and
will be fixed.

Bottom line: accept Lua plugins and servelets in text form only and sandbox
whatever is needed.