mirror of
https://git.proxmox.com/git/mirror_zfs.git
synced 2024-12-26 19:19:32 +03:00
3eabed74c0
The `zfs program` subcommand invokes a LUA interpreter to run ZFS "channel programs". This interpreter runs in a constrained environment, with defined memory limits. The LUA stack (used for LUA functions that call each other) is allocated in the kernel's heap, and is limited by the `-m MEMORY-LIMIT` flag and the `zfs_lua_max_memlimit` module parameter. The C stack is used by certain LUA features that are implemented in C. The C stack is limited by `LUAI_MAXCCALLS=20`, which limits call depth. Some LUA C calls use more stack space than others, and `gsub()` uses an unusually large amount. With a programming trick, it can be invoked recursively using the C stack (rather than the LUA stack). This overflows the 16KB Linux kernel stack after about 11 iterations, less than the limit of 20. One solution would be to decrease `LUAI_MAXCCALLS`. This could be made to work, but it has a few drawbacks: 1. The existing test suite does not pass with `LUAI_MAXCCALLS=10`. 2. There may be other LUA functions that use a lot of stack space, and the stack space may change depending on compiler version and options. This commit addresses the problem by adding a new limit on the amount of free space (in bytes) remaining on the C stack while running the LUA interpreter: `LUAI_MINCSTACK=4096`. If there is less than this amount of stack space remaining, a LUA runtime error is generated. Reviewed-by: George Wilson <gwilson@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Ryan Moeller <ryan@ixsystems.com> Reviewed-by: Allan Jude <allanjude@freebsd.org> Reviewed-by: Serapheim Dimitropoulos <serapheim@delphix.com> Signed-off-by: Matthew Ahrens <mahrens@delphix.com> Closes #10611 Closes #10613 |
||
---|---|---|
.. | ||
setjmp | ||
lapi.c | ||
lapi.h | ||
lauxlib.c | ||
lbaselib.c | ||
lcode.c | ||
lcode.h | ||
lcompat.c | ||
lcorolib.c | ||
lctype.c | ||
lctype.h | ||
ldebug.c | ||
ldebug.h | ||
ldo.c | ||
ldo.h | ||
lfunc.c | ||
lfunc.h | ||
lgc.c | ||
lgc.h | ||
llex.c | ||
llex.h | ||
llimits.h | ||
lmem.c | ||
lmem.h | ||
lobject.c | ||
lobject.h | ||
lopcodes.c | ||
lopcodes.h | ||
lparser.c | ||
lparser.h | ||
lstate.c | ||
lstate.h | ||
lstring.c | ||
lstring.h | ||
lstrlib.c | ||
ltable.c | ||
ltable.h | ||
ltablib.c | ||
ltm.c | ||
ltm.h | ||
lvm.c | ||
lvm.h | ||
lzio.c | ||
lzio.h | ||
Makefile.in | ||
README.zfs |
# # CDDL HEADER START # # This file and its contents are supplied under the terms of the # Common Development and Distribution License ("CDDL"), version 1.0. # You may only use this file in accordance with the terms of version # 1.0 of the CDDL. # # A full copy of the text of the CDDL should have accompanied this # source. A copy of the CDDL is also available via the Internet at # http://www.illumos.org/license/CDDL. # # CDDL HEADER END # # # Copyright (c) 2017 by Delphix. All rights reserved. # Introduction ------------ This README describes the Lua interpreter source code that lives in the ZFS source tree to enable execution of ZFS channel programs, including its maintenance policy, the modifications that have been made to it, and how it should (and should not) be used. For a description of the Lua language and features exposed by ZFS channel programs, please refer to the zfs-program(1m) man page instead. Maintenance policy ------------------ The Lua runtime is considered stable software. Channel programs don't need much complicated logic, so updates to the Lua runtime from upstream are viewed as nice-to-have, but not required for channel programs to be well-supported. As such, the Lua runtime in ZFS should be updated on an as-needed basis for security vulnerabilities, but not much else. Modifications to Lua -------------------- The version of the Lua runtime we're using in ZFS has been modified in a variety of ways to make it more useful for the specific purpose of running channel programs. These changes include: 1. "Normal" Lua uses floating point for all numbers it stores, but those aren't useful inside ZFS / the kernel. We have changed the runtime to use int64_t throughout for all numbers. 2. Some of the Lua standard libraries do file I/O or spawn processes, but neither of these make sense from inside channel programs. We have removed those libraries rather than reimplementing them using kernel APIs. 3. The "normal" Lua runtime handles errors by failing fatally, but since this version of Lua runs inside the kernel we must handle these failures and return meaningful error codes to userland. We have customized the Lua failure paths so that they aren't fatal. 4. Running poorly-vetted code inside the kernel is always a risk; even if the ability to do so is restricted to the root user, it's still possible to write an incorrect program that results in an infinite loop or massive memory use. We've added new protections into the Lua interpreter to limit the runtime (measured in number of Lua instructions run) and memory overhead of running a channel program. 5. The Lua bytecode is not designed to be secure / safe, so it would be easy to pass invalid bytecode which can panic the kernel. By comparison, the parser is hardened and fails gracefully on invalid input. Therefore, we only accept Lua source code at the ioctl level and then interpret it inside the kernel. Each of these modifications have been tested in the zfs-test suite. If / when new modifications are made, new tests should be added to the suite located in zfs-tests/tests/functional/channel_program/lua_core. How to use this Lua interpreter ------------------------------- From the above, it should be clear that this is not a general-purpose Lua interpreter. Additional work would be required to extricate this custom version of Lua from ZFS and make it usable by other areas of the kernel.