tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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    tel: +1-607-277-1029    fax: +1-607-277-6844

On 10/6/2010 7:14 PM, Matthew Mondor wrote:
On Wed, 6 Oct 2010 16:12:28 -0500
Javier Guerra Giraldez<>  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...


Home | Main Index | Thread Index | Old Index