On Wed, Oct 6, 2010 at 8:14 PM, Matthew Mondor <mm_li...@pulsar-zone.net> wrote:
> On Wed, 6 Oct 2010 16:12:28 -0500
> Javier Guerra Giraldez <jav...@guerrag.com> 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?

The number format was simply redefined to an integer type. We have no
built-in fixed point implementation, but you can provide floating
point as an external library or use your own fixed point
representation in your scripts.

> 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.

I do not see real problems in stack usage. I think the most important
concern is about liveness, but I would like to warn that liveness and
trust problems is also present in traditional loadable kernel modules.

> 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,
> --
> Matt
>

Cheers,
--
Lourival Vieira Neto

Reply via email to