Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Lua Scripting Support Added To NetBSD Kernel

  1. #1
    Join Date
    Jan 2007
    Posts
    14,335

    Default Lua Scripting Support Added To NetBSD Kernel

    Phoronix: Lua Scripting Support Added To NetBSD Kernel

    Earlier in the year I wrote about an initiative to bring Lua scripting support to the NetBSD kernel. With a Lua interpreter within the kernel, it would be easy to extend kernel subsystems, prototype new features, and lower the barrier to entry for NetBSD development. Well, that support for Lua has now been officially added to the NetBSD kernel...

    http://www.phoronix.com/vr.php?view=MTQ4ODk

  2. #2
    Join Date
    Oct 2013
    Posts
    8

    Default

    lol just lol

    So when can I start surfing the web using the kernel? Idiots.

    With the kernel now literally a Lua interpreter, everyone can now easily write kernel mode rootkits in Lua instead of C or assembly.

    Good job moronic NetBSD developers. Epic fail.
    Last edited by doggobot; 10-17-2013 at 10:32 PM.

  3. #3
    Join Date
    Jul 2010
    Posts
    20

    Default

    Quote Originally Posted by doggobot View Post
    lol just lol

    So when can I start surfing the web using the kernel? Idiots.

    With the kernel now literally a Lua interpreter, everyone can now easily write kernel mode rootkits in Lua instead of C or assembly.

    Good job moronic NetBSD developers. Epic fail.
    Without trying to feed the troll, I must say I'm skeptical as well. Integrating a programming language interpreter in a kernel seems like a Bad Idea(tm) that can only lead to bloat.

  4. #4
    Join Date
    Jan 2010
    Posts
    15

    Default

    I think this is a good idea. It's easier to debug and you don't have performance loss.

    Lua can be translated directly in C then compiled.
    Lua programs compiled with LuaJIT are as faster as C programs.

  5. #5
    Join Date
    Jan 2013
    Posts
    525

    Default

    Quote Originally Posted by doggobot View Post
    lol just lol

    So when can I start surfing the web using the kernel? Idiots.

    With the kernel now literally a Lua interpreter, everyone can now easily write kernel mode rootkits in Lua instead of C or assembly.

    Good job moronic NetBSD developers. Epic fail.
    Did you not read the article?
    Lua has no access to memory space if being invoked from the kernel, so it's going to be MORE work to exploit NetBSD through Lua than it is through C or assembly. If you're really that worried, you can compile the NetBSD kernel without Lua support.

  6. #6
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    555

    Default

    I haven't had time to read the original message so I may have missed something important, but I fail to see what's the actual use case in having LUA VM inside the kernel. (Beyond the cool factor)

    Though at least from security point of view is far easier to protect the kernel from a non binary kernel module (be that LUA or Phyton) that from a C/C++ binary module. (as long as you don't care about performance)

    - Gilboa
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX680, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  7. #7
    Join Date
    Oct 2010
    Posts
    85

    Default

    Quote Originally Posted by gilboa View Post
    I haven't had time to read the original message so I may have missed something important, but I fail to see what's the actual use case in having LUA VM inside the kernel. (Beyond the cool factor)

    Though at least from security point of view is far easier to protect the kernel from a non binary kernel module (be that LUA or Phyton) that from a C/C++ binary module. (as long as you don't care about performance)

    - Gilboa
    If the API available to it is suitably expanded, I imagine you could patch certain types of annoyances quite easily? ("This wifi card is known to freeze; but if you load this lua script that polls it every ten seconds and kicks the relevant restart function if it doesn't respond, it's usable enough until we fix it at a lower level"). Or I guess you could do some forms of monitoring- put in a small script to poll a bunch of things; create a device or something that it writes accumulated stats to. Or maybe you could do boot logic in it - e.g. "pull a file from here (based on my MAC address), parse it to find which iSCSI paths to mount where, and when that's done start /bin/init ".

    (Admittedly, much of that could be done without a kernel-side interpreter.)

    Besides, the LUA interpreter is tiny, and I don't really see the performance problem unless you start prototyping parts of the VM or network system in it...
    Last edited by dnebdal; 10-18-2013 at 08:07 AM.

  8. #8
    Join Date
    Feb 2013
    Posts
    275

    Default

    Quote Originally Posted by dnebdal View Post
    If the API available to it is suitably expanded, I imagine you could patch certain types of annoyances quite easily? ("This wifi card is known to freeze; but if you load this lua script that polls it every ten seconds and kicks the relevant restart function if it doesn't respond, it's usable enough until we fix it at a lower level"). Or I guess you could do some forms of monitoring- put in a small script to poll a bunch of things; create a device or something that it writes accumulated stats to. Or maybe you could do boot logic in it - e.g. "pull a file from here (based on my MAC address), parse it to find which iSCSI paths to mount where, and when that's done start /bin/init ".

    (Admittedly, much of that could be done without a kernel-side interpreter.)

    Besides, the LUA interpreter is tiny, and I don't really see the performance problem unless you start prototyping parts of the VM or network system in it...
    As you said, most of that can be done in userland. I think prototyping is actually the only real use-case for this.

  9. #9
    Join Date
    Jan 2013
    Posts
    525

    Default

    Quote Originally Posted by Serge View Post
    As you said, most of that can be done in userland. I think prototyping is actually the only real use-case for this.
    If the interpreter has virtually no footprint or security risk, then why not do those things from kernel space?
    It would also help those who only have experience in scripting languages to experiment with kernel code.

  10. #10
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    555

    Default

    Quote Originally Posted by dnebdal View Post
    If the API available to it is suitably expanded, I imagine you could patch certain types of annoyances quite easily? ("This wifi card is known to freeze; but if you load this lua script that polls it every ten seconds and kicks the relevant restart function if it doesn't respond, it's usable enough until we fix it at a lower level"). Or I guess you could do some forms of monitoring- put in a small script to poll a bunch of things; create a device or something that it writes accumulated stats to. Or maybe you could do boot logic in it - e.g. "pull a file from here (based on my MAC address), parse it to find which iSCSI paths to mount where, and when that's done start /bin/init ".

    (Admittedly, much of that could be done without a kernel-side interpreter.)

    Besides, the LUA interpreter is tiny, and I don't really see the performance problem unless you start prototyping parts of the VM or network system in it...
    Actually, before you mentioned it, I never noticed exactly how small (21K in x86_64) the LUA RT is. Thanks!
    Beyond that, I do understand the point, though, as you mentioned, in 99.9% of the cases the same can be achieved from user space without the security and stability risks involved.

    While I'm a sucker for kernel side programmer (@work), I usually use kernel space only when performance or security is an issue. In this case, neither one seem to be the case.

    - Gilboa
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX680, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •