Re: A proposal for safe bytecode in Lua 5.2

[Roberto Ierusalimschy <roberto@...>]

> I'm now looking for feedback on the proposal: Do you think it is a
> good proposal? Do the Lua authors think that inclusion of such a
> verifier is possible? Should I go ahead with spending time trying to
> break it? If the general consensus is positive, then I shall go ahead,
> and subsequently post a patch once I'm happy with it.

It sounds very good, but I do not think it will go into 5.2. It does
not looks mature enough (and we would have to understand it deeply to
go into the distribution ;).

Nevertheless, it seems interesting enough to deserve some support. We
could do the small changes and add appropriate macros so that users
could compile Lua with your verifier without having to change any
source.

Some questions about those changes:

> * Change the bytecode format to make startpc and endpc values for
> every local compulsory information rather than optional debug
> information (the name of the local remains as optional debug
> information).

Couldn't you simply reject source that do not have that information?


> * Reintroduce some checks which were present in 5.1: the
> non-negativity check in lundump.c's LoadInt, and the table type check
> in lvm.c's OP_SETLIST (as efficiently verifying the latter seems
> non-trivial).

I undestand the OP_SETLIST test, but shouldn't be easy for the verifier
to test whether integers are non-negative?


> * Two minor tweaks to the code generator: [...] and when the "local
> function" sugar is being compiled, shift the startpc value of the new
> local to not include the OP_CLOSURE (which makes it consistent with
> the non-sugared behaviour).

I did not understand this part. The non-sugared behaviour would be this:

  local f
  f = function (...) ... end

How the new local 'f' cannot include the OP_CLOSURE that follows its
declaration?

-- Roberto