mirror_zfs/module/lua
Alexander Lobakin b844489ec0 icp: properly fix all RETs in x86_64 Asm code
Commit 43569ee374 ("Fix objtool: missing int3 after ret warning")
addressed replacing all `ret`s in x86 asm code to a macro in the
Linux kernel in order to enable SLS. That was done by copying the
upstream macro definitions and fixed objtool complaints.
Since then, several more mitigations were introduced, including
Rethunk. It requires to have a jump to one of the thunks in order
to work, so the RET macro was changed again. And, as ZFS code
didn't use the mainline defition, but copied it, this is currently
missing.

Objtool reminds about it time to time (Clang 16, CONFIG_RETHUNK=y):

fs/zfs/lua/zlua.o: warning: objtool: setjmp+0x25: 'naked' return
 found in RETHUNK build
fs/zfs/lua/zlua.o: warning: objtool: longjmp+0x27: 'naked' return
 found in RETHUNK build

Do it the following way:
* if we're building under Linux, unconditionally include
  <linux/linkage.h> in the related files. It is available in x86
  sources since even pre-2.6 times, so doesn't need any conftests;
* then, if RET macro is available, it will be used directly, so that
  we will always have the version actual to the kernel we build;
* if there's no such macro, we define it as a simple `ret`, as it
  was on pre-SLS times.

This ensures we always have the up-to-date definition with no need
to update it manually, and at the same time is safe for the whole
variety of kernels ZFS module supports.
Then, there's a couple more "naked" rets left in the code, they're
just defined as:

	.byte 0xf3,0xc3

In fact, this is just:

	rep ret

`rep ret` instead of just `ret` seems to mitigate performance issues
on some old AMD processors and most likely makes no sense as of
today.
Anyways, address those rets, so that they will be protected with
Rethunk and SLS. Include <sys/asm_linkage.h> here which now always
has RET definition and replace those constructs with just RET.
This wipes the last couple of places with unpatched rets objtool's
been complaining about.

Reviewed-by: Attila Fülöp <attila@fueloep.org>
Reviewed-by: Tino Reichardt <milky-zfs@mcmilk.de>
Reviewed-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Lobakin <alobakin@pm.me>
Closes #14035
2022-11-04 11:24:09 -07:00
..
setjmp icp: properly fix all RETs in x86_64 Asm code 2022-11-04 11:24:09 -07:00
lapi.c lua: cast through uintptr_t when return a pointer 2022-11-03 09:52:28 -07:00
lapi.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lauxlib.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lbaselib.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lcode.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lcode.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lcompat.c Fix coverity defects: zfs channel programs 2018-02-20 11:19:42 -08:00
lcorolib.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lctype.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lctype.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
ldebug.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
ldebug.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
ldo.c Cleanup: Address Clang's static analyzer's unused code complaints 2022-10-14 13:37:54 -07:00
ldo.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lfunc.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lfunc.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lgc.c Rename fallthrough to zfs_fallthrough 2022-02-15 08:58:59 -08:00
lgc.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
llex.c Rename fallthrough to zfs_fallthrough 2022-02-15 08:58:59 -08:00
llex.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
llimits.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lmem.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lmem.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lobject.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lobject.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lopcodes.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lopcodes.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lparser.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lparser.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lstate.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lstate.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lstring.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lstring.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lstrlib.c Rename fallthrough to zfs_fallthrough 2022-02-15 08:58:59 -08:00
ltable.c Rename fallthrough to zfs_fallthrough 2022-02-15 08:58:59 -08:00
ltable.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
ltablib.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
ltm.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
ltm.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lvm.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lvm.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lzio.c Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
lzio.h Clean up CSTYLEDs 2022-01-26 11:38:52 -08:00
README.zfs OpenZFS 7431 - ZFS Channel Programs 2018-02-08 15:28:18 -08:00

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