[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.
tmm%mcci.com@localhost 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<javier%guerrag.com@localhost> wrote:
just curious, why was that needed? is floating point forbidden by
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...
Main Index |
Thread Index |