lneto

With GSoC approaching, I wrote an article on how to extend Lua with kernel APIs and embed the Lua interpreter into Linux subsystems using Lunatik—an in-kernel Lua runtime that enables dynamic scripting inside the Linux kernel without requiring recompilation.

The post covers key aspects of Lunatik bindings, including runtime management, integration into the framework, and practical examples like Xtables and kfifo.

Whether you're considering a GSoC project or just interested in kernel scripting with Lua, this article might be a useful reference!

Lunatik v3.6 Released

We are pleased to announce the release of Lunatik v3.6, introducing new features and improvements for in-kernel Lua scripting.

What is Lunatik?

Lunatik is an in-kernel Lua runtime that enables dynamic scripting within the Linux kernel, allowing extensions and modifications without recompilation. It provides a flexible way to develop networking features, security enhancements, and system automation.

What's New in v3.6?

New kernel bindings:

- Netfilter & Xtables – Packet filtering and firewall extensions

- Completion – Efficient synchronization primitives

- FIFO – Kernel-level queue management

Broader Kernel Support – Now compatible with Linux 5.x series

OpenWRT & OpenWiFi support – Expanding Lunatik to embedded and networking environments OpenWRT feed: https://github.com/luainkernel/openwrt_feed/tree/openwrt-23....

MoonScript support – A more expressive scripting option

New Examples:

- DNS Blocking – Filtering unwanted domains

- DNS Doctoring – Modifying DNS responses dynamically Bug Fixes & Stability Improvements

Acknowledgments

We would like to thank our contributors: @sav and @marcelstanley from Ring-0 Networks, @sheharyaar, @jperon, @vincentmli, @rustedusted, @glk0 – your contributions made this release possible.

We also appreciate the support from Google Summer of Code and Firas from 80211 Networks.

Join the Discussion

To discuss or contribute, join our Matrix room: https://matrix.to/#/#lunatik:matrix.org

Full release notes: https://github.com/luainkernel/lunatik/releases/tag/v3.6

Best regards, The Lunatik Team

It has been a while since we have introduced XDPLua, a Lua binding for running scripts inside the XDP (eXpress Data Path) environment using the Lunatik framework. Since then both XDP and Lunatik have evolved quite a bit. Especially, now it is possible to expose kernel functions (kfuncs) to eBPF programs, instead of relying only on eBPF Helpers. This feature finally allowed us to get rid of the hard requirement of running our Lua binding as built-in in the kernel and enabled us to run it as a kernel module. Moreover, Lunatik has also evolved towards a modular framework. Now we can develop new bindings for kernel subsystems as Lua libraries and link them as loadable kernel modules. Thus, leveraging these two features, we have created a new Lua binding for the XDP subsystem. We are glad to introduce in this article the new LuaXDP library!

Thanks for sharing this! Is it open source?

Potentially, yes. However, I didn't try it. You could even disable GC completely. Lunatik provides some facilities that could be useful in this scenario as well, such as RCU tables and shared objects. For instance, you could pre-allocate the entire memory to be used by your Lua states and treat them as volatile. In this case, you could persist state on the shared objects stored and synchronized through a RCU table. Of course, you could implement your own GC or tune the existent GC modes as well.

I've just glanced at LOAD81 now.. pretty good job! thanks for sharing.. I noted your keyboard event handling (using SDL).. we have something very related to this in Lunatik (at the kernel level, of course) [1]. We've a kinda fun script that uses keyboard event handling to implement a "key locker" using Konami code [2].

[1] https://github.com/luainkernel/lunatik?tab=readme-ov-file#no... [2] https://github.com/luainkernel/lunatik?tab=readme-ov-file#ke...

Please refer to Section 3 from [1], this was extensively discussed there.

[1] https://www.netbsd.org/~lneto/dls14.pdf

However, giving you a short answer, we use Lua mainly because it's easy both to extend and to embed. It's implemented as an almost "freestanding" C library. Moreover, it has a considerable small footprint (~250 KB) in comparison to other scripting languages (e.g., Python has a few MB). Moreover, Lua has automatic memory management, fully isolated execution states, protected calls, among other features.

One of the main inspirations for Lunatik is the MS Singularity OS [1], which gets rid of kernel/user space division and implements application/process protection by software using programing language resources. The other one is the MIT Exokernel [2], which provides a tiny kernel with almost no abstractions responsible only for safely multiplexing the hardware. Now, imagine a tiny kernel written in C, exposing Lua APIs, responsible mainly for multiplexing HW; and user processes implemented as separate Lua states running on the same address space, protected by language constructs.

[1] https://pdos.csail.mit.edu/6.828/2008/readings/hunt07singula... [2] https://www.classes.cs.uchicago.edu/archive/2019/winter/3310...

https://imgflip.com/i/8njfrr

the most explored use case is for scripting networking, please see:

[1] https://legacy.netdevconf.info/0x14/session.html?talk-linux-... [2] https://netdevconf.info/0x17/sessions/talk/scripting-the-lin... [3] https://www.netbsd.org/~lneto/dls14.pdf [4] https://www.slideshare.net/eurobsdcon/lneto-npf-scripting [5] https://2018.eurobsdcon.org/static/slides/Fast,%20Flexible%2...

However, it was conceived for extensibility and flexibility in general, in the spirit of [6]. It has been used also for scripting CPU frequency scaling, debugging, application sandboxing among others [7,8].

[6] https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pd... [7] https://drive.google.com/file/d/1TJ50IEbRXlBz-TxheGdkO-b4vLS... [8] https://youtu.be/-ufBgy044HI?si=IT4FOqeldA-jsg2r (Portuguese only)

ZFS also has its own kernel Lua version (I'd love to unify them, BTW).

Moreover, we have some simplified examples on our repository [9].

[9] https://github.com/luainkernel/lunatik?tab=readme-ov-file#ex...

Perhaps when we have a fully scriptable operating system, we might call it Lunatix =).

https://dl.acm.org/doi/10.1145/1238844.1238846 =)

this is because the repository is a Lua fork.. actually, Lunatik started in 2008 [1, 2].

[1] https://sourceforge.net/projects/lunatik/files/ [2] https://www.maxwell.vrac.puc-rio.br/colecao.php?strSecao=res... (Portuguese only)

It doesn't use eBPF but we can interoperate.. we have developed XDPLua for this as a GSoC project [1] and then published this work on Netdev 0x14 [2].

[1] https://victornogueirario.github.io/xdplua/ [2] https://netdevconf.info/0x14/session.html?talk-linux-network...

I'm currently working on updating XDPLua for using kfuncs on top of the newest version of Lunatik.. I've a PoC already and should create a PR in a few weeks.

Happy to see this on HN =). Lunatik’s main author here. AMA.

Please feel welcome to join us on Matrix [1] as well.

[1] https://matrix.to/#/#lunatik:matrix.org

a bit of history.. https://mail-index.netbsd.org/tech-kern/2010/10/05/msg008900...

it's totally related.. we started with Lunatik in Linux actually then ported it to NetBSD..

[1] https://www.netbsd.org/~lneto/dls14.pdf

Please take a look at:

[1] https://netdevconf.info/0x14/session.html?talk-linux-network... [2] https://netdevconf.info/0x17/sessions/talk/scripting-the-lin...

I'm currently updating XDPLua and we might have a GSoC project on updating NFLua this year =)..

[3] http://www.lua.inf.puc-rio.br/gsoc/ideas2024.html#lunatik-ne...

This work ran more benchmarks with NPFLua:

https://2018.eurobsdcon.org/static/slides/Fast,%20Flexible%2...

We have also integrated Lua with Netfilter and XDP on Linux, filtering up to 5.3 Gbps.

https://netdevconf.info/0x14/session.html?talk-linux-network...

If interested, you may want to glance at https://github.com/luainkernel/lunatik