Announcement

Collapse
No announcement yet.

Lua Scripting Support Added To NetBSD Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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; 17 October 2013, 10:32 PM.

    Comment


    • #3
      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.

      Comment


      • #4
        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.

        Comment


        • #5
          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.

          Comment


          • #6
            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
            oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
            oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
            oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
            Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

            Comment


            • #7
              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; 18 October 2013, 08:07 AM.

              Comment


              • #8
                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.

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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
                    oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
                    oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
                    oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
                    Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

                    Comment

                    Working...
                    X