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