[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: RE: future of bytecode verifier
- From: "John Hind" <john.hind@...>
- Date: Thu, 5 Mar 2009 13:34:48 -0000
Hm ... now I am missing something. You are suggesting that lua_load is still
there but is administratively deprecated and new code is encouraged to use a
new function, luaL_load instead? So luaL_loadbuffer, luaL_loadfile and
luaL_loadstring would all require the extra "nobinary" flag as well?
Stepping back a moment, I'd suggest this is a case where it would be *good*
to break compatibility - just for the binary file case. This is because you
are effectively transferring a security responsibility from core to API
which conceptually breaks compatibility anyway. Current API users may be
relying on the existing bytecode validation (although not perfect it is good
enough, as they say "for government work") and you are proposing
transferring this responsibility to them, which they should think very
carefully about when upgrading to the new Lua version.
So I would suggest actually restricting *all* the current reading functions
to parser input and adding new reading functions for bytecodes.
I agree strongly that removing bytecode validation is *the right thing to
do* but it is necessarily a big deal for existing bytecode users and given
this you may as well do it the *right* rather than the *easy* way. And I do
realise that this is easier for me to suggest than for you to do - sorry!
-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Luiz Henrique de
Figueiredo
Sent: 05 March 2009 11:37
To: Lua list
Subject: Re: future of bytecode verifier
> OK, but I do not think the proposed mechanism is optimal, at the 'C'
level.
> Firstly the lua_Reader function replacement has to process the internals
of
> the bytecode format thus breaking containment
I'm probably missing something, but testing in a lua_Reader function
whether the input is binary is simply testing whether the first byte is
LUA_SIGNATURE[0], as luaL_loadfile does.
That said, we could write a convenience function like this:
typedef struct {
int first;
lua_Reader f;
void *data;
} Safedata;
static const char *safe (lua_State *L, void *ud, size_t *size) {
Safedata *d = (Safedata*) ud;
const char *s = d->f(L,d->data,size);
if (d->first) {
d->first = 0;
if (s!=NULL && *size!=0 && s[0]==LUA_SIGNATURE[0])
luaL_error(L,"cannot load binary files");
}
return (*size > 0) ? s : NULL;
}
LUALIB_API int luaL_load (lua_State *L, lua_Reader f, void *data,
const char *chunkname, int nobinary) {
Safedata d;
d.first=nobinary;
d.f=f;
d.data=data;
return lua_load(L, safe, &d, chunkname);
}
Attachment:
smime.p7s
Description: S/MIME cryptographic signature