Re: Bytecode abuse in Lua 5.2 (-work4)

[John Passaniti <john@...>]

On Sun, Aug 22, 2010 at 7:54 AM, KHMan <keinhong@gmail.com> wrote:
> Performance is not really a big issue if one thinks practically. A
> very middling PC can load minimal-whitespace Lua source text
> from memory at a rate of at least 4MB/sec.

<comment class="side">
I know I and a few others here represent a minority in that we target
Lua for embedded systems which are not in any way PCs (ColdFire,
lower-end ARM, etc.).  But I would hope assumptions made about speedy
platforms with gobs of memory don't dictate the design decisions of
Lua.  In this particular case, I agree-- Lua can read source code very
quickly, although 4MB/sec isn't likely on my 60MHz ColdFire target.
Further, it's difficult to compile Lua source when you don't include
Lua's compiler in the build.  Regardless, the larger point remains:
Lua is used in more than beefy PC platforms; please remember us.
</comment>

> So no loading untrusted bytecode if there is a need for trust...

Well, yeah.  But I think a useful conversation to have would be what
would need to change or need to be added to Lua in order to make it
secure from these kinds of attacks, and what are the costs of that
security.  I'm not so naive to think that just because a language
offers a bytecode verifier that I don't have to worry about security
(take for example, Java).  But I also don't want to take the attitude
of it being some intractable problem and have to choose from binary
options like having no security or completely shutting the application
off from the outside.  Security isn't a binary proposition; it's a
continuum.  It would be nice if Lua had compile-time options that let
those building it into systems that offered varying levels of security
(with presumably varying run-time costs associated with them).