Re: dostring and precompiled code

["Cary O'Brien" <cobrien@...>]

[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> --- In lua-l@y..., Adolf Mathias <dolfi@z...> wrote:
> > The compiler is in a position to (theoretically) construct VM code 
> > that is safe.Safe in a sense that it doesn't, say, do things or call
> > functions that it's not supposed to. This is not the case with
> > precompiled code in a string, since it can contain about anything 
> > that the VM can do. 
> > <paranoia mode on>
> > The only place for precompiled code that resides in memory is in a 
> > data type that has no other access possibilities but execution and 
> > might have some cryptographic signature in order to prove that it  
> > has not been altered in some way.
> > <paranoia mode off>
> 
> Beg to disgree here. Security vetting of code does not belong in the 
> compiler. It belongs in the VM, or more properly, in the external 
> functions available to the VM. If you want secure file IO for 
> instance, the way to implement it is not to add an extra verification 
> pass to the interpreter (what for?) but to ensure that the only Lua-
> callable file IO functions available to that particular Lua instance 
> contain verification routines (eg user/password checks). This is one 
> of the strong points of Lua as it exists, that the Lua core comes 
> with very few intrinsic functions; everything including IO is located 
> in external libraries. 
> 

As a point of external reference, python has something called "bytecode-hacks"
that allows manipulation of bytecodes.  Zope uses this for a feature called
"python scripts" which allows somewhat untrusted users to enter python
code through a web interface.  Zope then (I think) uses bytecode-hacks
to restrict what code can be executed.  The point?  I guess you could
scan Lua bytecode before execution.

Another question (ok, I know 10 minutes with the source code and I could
figure this out myself): are all sequences of bytecodes safe?  At least
in terms of keeping the interpreter running?  No HCF or FOOF [1] instructions?

-- cary

[1] HCF - halt catch fire - an instruction on a particular single-chip
    micro that would turn on opposing output buffers.  Chip would melt.

[2] Pentium opcode that caused lockup.


> The only difference between bytecode and source code is (or should 
> be) compactness of representation, and differences due to 
> optimization, macro expansion etc. Source code is basically human-
> readable bytecode. 
> 
> Cheers, Elliott
>