Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project

[Terry Moore <tmm%mcci.com@localhost>]

Stack usage should not be a risk.  Unless Lua has changed a lot in the 
porting process (which I doubt), recursion does not use the CPU stack at 
all.  Stack size of the virtual machine interpreter is fixed (and 
limited).  Recursion does use memory, but that's acquired/released via 
something like malloc().

All the other security issues that arise when you allow scripts to be 
loaded into the kernel need to be considered, of course.

--Terry

tmm%mcci.com@localhost    tel: +1-607-277-1029    fax: +1-607-277-6844    
www.mcci.com


On 10/6/2010 7:14 PM, Matthew Mondor wrote:
> On Wed, 6 Oct 2010 16:12:28 -0500
> Javier Guerra Giraldez<javier%guerrag.com@localhost>  wrote:
>
>    
> > just curious, why was that needed?   is floating point forbidden by
> > code conventions?
> >      
> The non-software floating point support is only available in userland
> if I remember.  However I also have a question: is switching to long
> long including the switch to a fixed point implementation, or is it
> an integer-only Lua implementation for kernel use?
>
> As for possible problems like stack usage, I guess that if it's running
> under an LWP context it probably is less restricted, but I agree that
> preventing interpretation of non-trusted scripts would be better than
> trying to cripple the Lua runtime as much as possible.  Considering
> that the cryptographic code export is now less restrictive than it used
> to be, possibly that signature checking would also be nice to have,
> other than only limiting access to the superuser.
>
> In fact, that would be nice for new-style kernel modules, too,
> especially if part of future plans for supporting them include
> eventually providing binary-only upgrades of some components).
> A build-time inclusion of the wanted public keys to trust third party
> components from would not be hard to implement...
>
> Thanks,
>