[6.6] [Feature] [Security] : import Lua runtime support and Lua-LSM · Pull Request !6681 · anolis/cloud-kernel

bugzilla: https://bugzilla.openanolis.cn/show_bug.cgi?id=31935

This series introduces in-kernel Lua runtime support and adds Lua-LSM on top of it.

The first part of the series brings in the Lua pieces needed to run a small, self-contained Lua 5.1 VM inside the kernel. That includes the public headers, the internal runtime sources, and the low-level support needed by the VM, including the setjmp/longjmp implementation used by the Lua execution model. The intention is not to scatter a scripting engine across unrelated subsystems, but to provide a compact and well-bounded runtime that can serve as a foundation for kernel components that benefit from a programmable policy layer.

The main user of that runtime in this series is Lua-LSM. Lua-LSM is a Linux Security Module that lets policy be expressed in Lua while keeping policy enforcement in the normal LSM path. The guiding idea is simple: move policy expression into a language that is easier to write, review, and iterate on, while leaving the actual security decision point where it already belongs. The result is a system that remains kernel-resident and LSM-driven, but is much more flexible than an implementation where every policy change requires editing C code and rebuilding a dedicated policy engine around it.

The series includes the core Lua-LSM runtime under security/lua, the helper bridge between the VM and kernel objects, the object model used to expose kernel and LSM state to Lua, the built-in libraries for common functionality such as kernel, filesystem, networking, errno, capability, and signal handling, the hook wrapper framework, and the integration needed to register the LSM and expose its runtime control surface through securityfs.

The design tries to keep the layering explicit. The Lua runtime is introduced first as the substrate. Lua-LSM is then built on top of that substrate as a concrete consumer. Within Lua-LSM itself, the hook side and the Lua-facing API are kept separate enough that the policy author sees ordinary Lua objects and helper libraries rather than a thin textual dump of internal kernel structures. In practice that means a module can be written as a Lua chunk that returns metadata and a set of hook functions, while the wrapper layer takes care of translating LSM arguments into a form that is natural to use from Lua.

A small example may help explain the intent. A policy module can implement file_open, obtain the path from the file object, and deny access to /etc/shadow by returning false, errno.EPERM. That is a trivial example, but it shows the model clearly: the hook remains an LSM hook, the decision is still made synchronously in the kernel, but the policy itself is expressed in a compact and readable

The series also tries to make Lua-LSM observable enough to be practical. With the optional stats and debug configuration enabled, it exposes module information, VM and memory statistics, and per-hook timing data through securityfs, and it can emit debug logs tagged with task and function context. For something that executes in security hooks, that kind of visibility matters, both for development and for understanding real-world policy cost.

Comments are very welcome, especially on the runtime integration, the VM sandbox, the object exposure model, and whether the Lua-facing API looks like a reasonable balance between flexibility and restraint.

The import includes the full stack needed to make that work:
 - Lua runtime support and related headers
 - architecture support for setjmp/longjmp
 - the security/lua core runtime, sandbox, object model, and module lifecycle
 - built-in Lua modules for common kernel-facing functionality
 - the hook wrapper framework and the LSM hook bindings
 - Kconfig / Makefile plumbing and top-level integration

类型	指派人员	状态
审查	Tianjia Zhang Shiloong xunlei 半叶枫尘 Artie Ding winterddd xueshuai alu 小龙冯光辉 Guixin Liu kun-llfl Xuchun Shang	已完成 (0/0人)
测试	小龙	进行中 (0/1人)

GVPanolis/cloud-kernel

搜索帮助

GVP anolis/cloud-kernel