[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project
On Tue, Oct 12, 2010 at 1:50 AM, David Holland
> On Tue, Oct 12, 2010 at 12:53:10AM -0300, Lourival Vieira Neto wrote:
> > > > > A signature only tells you whose neck to wring when the script
> > > > > misbehaves. :-) Since a Lua script running in the kernel won't be
> > > > > able to forge a pointer (right?), or conjure references to methods or
> > > > > data that weren't in its environment at the outset, you can run it
> > > > > in a highly restricted environment so that many kinds of misbehavior
> > > > > are difficult or impossible. ?Or I would *think* you can restrict the
> > > > > environment in that way; I wonder what Lourival thinks about that.
> > > >
> > > > I wouldn't say better =). That's exactly how I'm thinking about
> > > > address this issue: restricting access to each Lua environment. For
> > > > example, a script running in packet filtering should have access to a
> > > > different set of kernel functions than a script running in process
> > > > scheduling.
> > >
> > > ...so what do you do if the script calls a bunch of kernel functions
> > > and then crashes?
> > if a script crashes, it raises an exception that can be caught by the
> > kernel (as an error code)..
> Right... so how do you restore the kernel to a valid state?
Why wouldn't it be a valid state after a script crash? I didn't get
that. Can you exemplify it?
Lourival Vieira Neto
Main Index |
Thread Index |