From: "Madhavan T. Venkataraman" <[email protected]>
Introduction
============
Dynamic code is used in many different user applications. Dynamic code is
often generated at runtime. Dynamic code can also just be a pre-defined
sequence of machine instructions in a data buffer. Examples of dynamic
code are trampolines, JIT code, DBT code, etc.
Dynamic code is placed either in a data page or in a stack page. In order
to execute dynamic code, the page it resides in needs to be mapped with
execute permissions. Writable pages with execute permissions provide an
attack surface for hackers. Attackers can use this to inject malicious
code, modify existing code or do other harm.
To mitigate this, LSMs such as SELinux implement W^X. That is, they may not
allow pages to have both write and execute permissions. This prevents
dynamic code from executing and blocks applications that use it. To allow
genuine applications to run, exceptions have to be made for them (by setting
execmem, etc) which opens the door to security issues.
The W^X implementation today is not complete. There exist many user level
tricks that can be used to load and execute dynamic code. E.g.,
- Load the code into a file and map the file with R-X.
- Load the code in an RW- page. Change the permissions to R--. Then,
change the permissions to R-X.
- Load the code in an RW- page. Remap the page with R-X to get a separate
mapping to the same underlying physical page.
IMO, these are all security holes as an attacker can exploit them to inject
his own code.
In the future, these holes will definitely be closed. For instance, LSMs
(such as the IPE proposal [1]) may only allow code in properly signed object
files to be mapped with execute permissions. This will do two things:
- user level tricks using anonymous pages will fail as anonymous
pages have no file identity
- loading the code in a temporary file and mapping it with R-X
will fail as the temporary file would not have a signature
We need a way to execute such code without making security exceptions.
Trampolines are a good example of dynamic code. A couple of examples
of trampolines are given below. My first use case for this RFC is
libffi.
Examples of trampolines
=======================
libffi (A Portable Foreign Function Interface Library):
libffi allows a user to define functions with an arbitrary list of
arguments and return value through a feature called "Closures".
Closures use trampolines to jump to ABI handlers that handle calling
conventions and call a target function. libffi is used by a lot
of different applications. To name a few:
- Python
- Java
- Javascript
- Ruby FFI
- Lisp
- Objective C
GCC nested functions:
GCC has traditionally used trampolines for implementing nested
functions. The trampoline is placed on the user stack. So, the stack
needs to be executable.
Currently available solution
============================
One solution that has been proposed to allow trampolines to be executed
without making security exceptions is Trampoline Emulation. See:
https://pax.grsecurity.net/docs/emutramp.txt
In this solution, the kernel recognizes certain sequences of instructions
as "well-known" trampolines. When such a trampoline is executed, a page
fault happens because the trampoline page does not have execute permission.
The kernel recognizes the trampoline and emulates it. Basically, the
kernel does the work of the trampoline on behalf of the application.
Currently, the emulated trampolines are the ones used in libffi and GCC
nested functions. To my knowledge, only X86 is supported at this time.
As noted in emutramp.txt, this is not a generic solution. For every new
trampoline that needs to be supported, new instruction sequences need to
be recognized by the kernel and emulated. And this has to be done for
every architecture that needs to be supported.
emutramp.txt notes the following:
"... the real solution is not in emulation but by designing a kernel API
for runtime code generation and modifying userland to make use of it."
Solution proposed in this RFC
=============================
From this RFC's perspective, there are two scenarios for dynamic code:
Scenario 1
----------
We know what code we need only at runtime. For instance, JIT code generated
for frequently executed Java methods. Only at runtime do we know what
methods need to be JIT compiled. Such code cannot be statically defined. It
has to be generated at runtime.
Scenario 2
----------
We know what code we need in advance. User trampolines are a good example of
this. It is possible to define such code statically with some help from the
kernel.
This RFC addresses (2). (1) needs a general purpose trusted code generator
and is out of scope for this RFC.
For (2), the solution is to convert dynamic code to static code and place it
in a source file. The binary generated from the source can be signed. The
kernel can use signature verification to authenticate the binary and
allow the code to be mapped and executed.
The problem is that the static code has to be able to find the data that it
needs when it executes. For functions, the ABI defines the way to pass
parameters. But, for arbitrary dynamic code, there isn't a standard ABI
compliant way to pass data to the code for most architectures. Each instance
of dynamic code defines its own way. For instance, co-location of code and
data and PC-relative data referencing are used in cases where the ISA
supports it.
We need one standard way that would work for all architectures and ABIs.
The solution proposed here is:
1. Write the static code assuming that the data needed by the code is already
pointed to by a designated register.
2. Get the kernel to supply a small universal trampoline that does the
following:
- Load the address of the data in a designated register
- Load the address of the static code in a designated register
- Jump to the static code
User code would use a kernel supplied API to create and map the trampoline.
The address values would be baked into the code so that no special ISA
features are needed.
To conserve memory, the kernel will pack as many trampolines as possible in
a page and provide a trampoline table to user code. The table itself is
managed by the user.
Trampoline File Descriptor (trampfd)
==========================
I am proposing a kernel API using anonymous file descriptors that can be
used to create the trampolines. The API is described in patch 1/4 of this
patchset. I provide a summary here:
- Create a trampoline file object
- Write a code descriptor into the trampoline file and specify:
- the number of trampolines desired
- the name of the code register
- user pointer to a table of code addresses, one address
per trampoline
- Write a data descriptor into the trampoline file and specify:
- the name of the data register
- user pointer to a table of data addresses, one address
per trampoline
- mmap() the trampoline file. The kernel generates a table of
trampolines in a page and returns the trampoline table address
- munmap() a trampoline file mapping
- Close the trampoline file
Each mmap() will only map a single base page. Large pages are not supported.
A trampoline file can only be mapped once in an address space.
Trampoline file mappings cannot be shared across address spaces. So,
sending the trampoline file descriptor over a unix domain socket and
mapping it in another process will not work.
It is recommended that the code descriptor and the code table be placed
in the .rodata section so an attacker cannot modify them.
Trampoline use and reuse
========================
The code for trampoline X in the trampoline table is:
load &code_table[X], code_reg
load (code_reg), code_reg
load &data_table[X], data_reg
load (data_reg), data_reg
jump code_reg
The addresses &code_table[X] and &data_table[X] are baked into the
trampoline code. So, PC-relative data references are not needed. The user
can modify code_table[X] and data_table[X] dynamically.
For instance, within libffi, the same trampoline X can be used for different
closures at different times by setting:
data_table[X] = closure;
code_table[X] = ABI handling code;
Advantages of the Trampoline File Descriptor approach
=====================================================
- Using this support from the kernel, dynamic code can be converted to
static code with a little effort so applications and libraries can move to
a more secure model. In the simplest cases such as libffi, dynamic code can
even be eliminated.
- This initial work is targeted towards X86 and ARM. But it can be supported
easily on all architectures. We don't need any special ISA features such
as PC-relative data referencing.
- The only code generation needed is for this small, universal trampoline.
- The kernel does not have to deal with any ABI issues in the generation of
this trampoline.
- The kernel provides a trampoline table to conserve memory.
- An SELinux setting called "exectramp" can be implemented along the
lines of "execmem", "execstack" and "execheap" to selectively allow the
use of trampolines on a per application basis.
- In version 1, a trip to the kernel was required to execute the trampoline.
In version 2, that is not required. So, there are no performance
concerns in this approach.
libffi
======
I have implemented my solution for libffi and provided the changes for
X86 and ARM, 32-bit and 64-bit. Here is the reference patch:
http://linux.microsoft.com/~madvenka/libffi/libffi.v2.txt
If the trampfd patchset gets accepted, I will send the libffi changes
to the maintainers for a review. BTW, I have also successfully executed
the libffi self tests.
Work that is pending
====================
- I am working on implementing the SELinux setting - "exectramp".
- I have a test program to test the kernel API. I am working on adding it
to selftests.
References
==========
[1] https://microsoft.github.io/ipe/
---
Changelog:
v1
Introduced the Trampfd feature.
v2
- Changed the system call. Version 2 does not support different
trampoline types and their associated type structures. It only
supports a kernel generated trampoline.
The system call now returns information to the user that is
used to define trampoline descriptors. E.g., the maximum
number of trampolines that can be packed in a single page.
- Removed all the trampoline contexts such as register contexts
and stack contexts. This is based on the feedback that the kernel
should not have to worry about ABI issues and H/W features that
may deal with the context of a process.
- Removed the need to make a trip into the kernel on trampoline
invocation. This is based on the feedback about performance.
- Removed the ability to share trampolines across address spaces.
This would have made sense to different trampoline types based
on their semantics. But since I support only one specific
trampoline, sharing does not make sense.
- Added calls to specify trampoline descriptors that the kernel
uses to generate trampolines.
- Added architecture-specific code to generate the small, universal
trampoline for X86 32 and 64-bit, ARM 32 and 64-bit.
- Implemented the trampoline table in a page.
Madhavan T. Venkataraman (4):
Implement the kernel API for the trampoline file descriptor.
Implement i386 and X86 support for the trampoline file descriptor.
Implement ARM64 support for the trampoline file descriptor.
Implement ARM support for the trampoline file descriptor.
arch/arm/include/uapi/asm/ptrace.h | 21 +++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/trampfd.c | 124 +++++++++++++
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/arm64/include/uapi/asm/ptrace.h | 59 ++++++
arch/arm64/kernel/Makefile | 2 +
arch/arm64/kernel/trampfd.c | 244 +++++++++++++++++++++++++
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/x86/include/uapi/asm/ptrace.h | 38 ++++
arch/x86/kernel/Makefile | 1 +
arch/x86/kernel/trampfd.c | 238 ++++++++++++++++++++++++
fs/Makefile | 1 +
fs/trampfd/Makefile | 5 +
fs/trampfd/trampfd_fops.c | 241 ++++++++++++++++++++++++
fs/trampfd/trampfd_map.c | 142 ++++++++++++++
include/linux/syscalls.h | 2 +
include/linux/trampfd.h | 49 +++++
include/uapi/asm-generic/unistd.h | 4 +-
include/uapi/linux/trampfd.h | 184 +++++++++++++++++++
init/Kconfig | 7 +
kernel/sys_ni.c | 3 +
24 files changed, 1371 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/kernel/trampfd.c
create mode 100644 arch/arm64/kernel/trampfd.c
create mode 100644 arch/x86/kernel/trampfd.c
create mode 100644 fs/trampfd/Makefile
create mode 100644 fs/trampfd/trampfd_fops.c
create mode 100644 fs/trampfd/trampfd_map.c
create mode 100644 include/linux/trampfd.h
create mode 100644 include/uapi/linux/trampfd.h
--
2.17.1
From: "Madhavan T. Venkataraman" <[email protected]>
Introduction
============
Dynamic code is used in many different user applications. Dynamic code is
often generated at runtime. Dynamic code can also just be a pre-defined
sequence of machine instructions in a data buffer. Examples of dynamic
code are trampolines, JIT code, DBT code, etc.
Dynamic code is placed either in a data page or in a stack page. In order
to execute dynamic code, the page it resides in needs to be mapped with
execute permissions. Writable pages with execute permissions provide an
attack surface for hackers. Attackers can use this to inject malicious
code, modify existing code or do other harm.
To mitigate this, LSMs such as SELinux implement W^X. That is, they may not
allow pages to have both write and execute permissions. This prevents
dynamic code from executing and blocks applications that use it. To allow
genuine applications to run, exceptions have to be made for them (by setting
execmem, etc) which opens the door to security issues.
The W^X implementation today is not complete. There exist many user level
tricks that can be used to load and execute dynamic code. E.g.,
- Load the code into a file and map the file with R-X.
- Load the code in an RW- page. Change the permissions to R--. Then,
change the permissions to R-X.
- Load the code in an RW- page. Remap the page with R-X to get a separate
mapping to the same underlying physical page.
IMO, these are all security holes as an attacker can exploit them to inject
his own code.
In the future, these holes will definitely be closed. For instance, LSMs
(such as the IPE proposal [1]) may only allow code in properly signed object
files to be mapped with execute permissions. This will do two things:
- user level tricks using anonymous pages will fail as anonymous
pages have no file identity
- loading the code in a temporary file and mapping it with R-X
will fail as the temporary file would not have a signature
We need a way to execute such code without making security exceptions.
Trampolines are a good example of dynamic code. A couple of examples
of trampolines are given below. My first use case for this RFC is
libffi.
Solution
========
The solution is to convert dynamic code to static code and place it in a
source file. The binary generated from the source can be signed. The kernel
can use signature verification to authenticate the binary and allow the code
to be mapped and executed.
The problem is that the static code has to be able to find the data that it
needs when it executes. For functions, the ABI defines the way to pass
parameters. But, for arbitrary dynamic code, there isn't a standard ABI
compliant way to pass data to the code for most architectures. Each instance
of dynamic code defines its own way. For instance, co-location of code and
data and PC-relative data referencing are used in cases where the ISA
supports it.
We need one standard way that would work for all architectures and ABIs.
The solution has two parts:
1. The maintainer of the code writes the static code assuming that the data
needed by the code is already pointed to by a designated register.
2. The kernel supplies a small universal trampoline that does the following:
- Load the address of the data in a designated register
- Load the address of the static code in a designated register
- Jump to the static code
User code would use a kernel supplied API to create and map the trampoline.
The address values would be baked into the code so that no special ISA
features are needed.
To conserve memory, the kernel will pack as many trampolines as possible in
a page and provide a trampoline table to user code. The table itself is
managed by the user.
Kernel API
==========
A kernel API based on anonymous file descriptors is defined to create
trampolines. The following sections describe the API.
Create trampfd
==============
This feature introduces a new trampfd system call.
struct trampfd_info info;
int trampfd;
trampfd = syscall(440, &info);
The kernel creates a trampoline file object and returns the following items
in info:
ntrampolines
The number of trampolines that can be created with one trampfd. The
user may create fewer trampolines if he wishes.
code_size
The size of each trampoline.
code_offset
The file offset to be used in mmap() to map the trampoline code.
Initialize trampfd
==================
A trampfd is initialized in this manner:
struct trampfd_code code;
struct trampfd_data data;
/*
* Code descriptor.
*/
code.ntrampolines = number of desired trampolines;
code.reg = code register name;
code.table = array of code addresses
/*
* Data descriptor.
*/
data.reg = data register name;
data.table = array of data addresses
pwrite(trampfd, &code, sizeof(init), TRAMPFD_CODE);
pwrite(trampfd, &data, sizeof(init), TRAMPFD_DATA);
The register names are defined in ptrace.h (reg_32_name and reg_64_name).
It is recommended that the code descriptor and code array be placed in the
.rodata section so that an attacker cannot modify its contents.
Instead of pwrite(), the user can also do lseek() and write().
Map trampfd
===========
The user uses mmap() to map the trampoline table into user address space.
len = info.code_size * code.ntrampolines;
prot = PROT_READ | PROT_EXEC;
flags = MAP_PRIVATE;
offset = info.code_offset;
trampoline_table = mmap(NULL, len, prot, flags, trampfd, offset);
The kernel generates the trampoline table. The code for trampoline X in the
table is:
load &code_table[X], code_reg
load (code_reg), code_reg
load &data_table[X], data_reg
load (data_reg), data_reg
jump code_reg
Each mmap() will only map a single base page. Large pages are not supported.
A trampoline file can only be mmapped once in an address space.
Trampoline file mappings cannot be shared across address spaces. So,
sending the trampoline file descriptor over a unix domain socket and
mapping it in another process will not work.
The trampoline code is generated with &code_table[X] and &data_table[X] hard
coded in it. But code_table[X] and data_table[X] can be modified by user
code dynamically so supply the code and data to trampoline X.
Trampoline table management
===========================
The user manages the trampoline table. The address of trampoline X is:
trampoline_table + info.code_size * X;
Prior to invoking trampoline X, the user must initialize code_table[X] and
data_table[X].
Unmap trampfd
=============
Once the user is done with the trampoline table, it may be unmapped:
len = info.code_size * code.ntrampolines;
munmap(trampoline_table, len);
Remove trampfd
==============
To remove the trampfd:
close(trampfd);
Signed-off-by: Madhavan T. Venkataraman <[email protected]>
---
fs/Makefile | 1 +
fs/trampfd/Makefile | 5 +
fs/trampfd/trampfd_fops.c | 241 ++++++++++++++++++++++++++++++
fs/trampfd/trampfd_map.c | 142 ++++++++++++++++++
include/linux/syscalls.h | 2 +
include/linux/trampfd.h | 49 ++++++
include/uapi/asm-generic/unistd.h | 4 +-
include/uapi/linux/trampfd.h | 184 +++++++++++++++++++++++
init/Kconfig | 7 +
kernel/sys_ni.c | 3 +
10 files changed, 637 insertions(+), 1 deletion(-)
create mode 100644 fs/trampfd/Makefile
create mode 100644 fs/trampfd/trampfd_fops.c
create mode 100644 fs/trampfd/trampfd_map.c
create mode 100644 include/linux/trampfd.h
create mode 100644 include/uapi/linux/trampfd.h
diff --git a/fs/Makefile b/fs/Makefile
index 2ce5112b02c8..227761302000 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -136,3 +136,4 @@ obj-$(CONFIG_EFIVAR_FS) += efivarfs/
obj-$(CONFIG_EROFS_FS) += erofs/
obj-$(CONFIG_VBOXSF_FS) += vboxsf/
obj-$(CONFIG_ZONEFS_FS) += zonefs/
+obj-$(CONFIG_TRAMPFD) += trampfd/
diff --git a/fs/trampfd/Makefile b/fs/trampfd/Makefile
new file mode 100644
index 000000000000..ae09a0b1f841
--- /dev/null
+++ b/fs/trampfd/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_TRAMPFD) += trampfd.o
+
+trampfd-y += trampfd_fops.o trampfd_map.o
diff --git a/fs/trampfd/trampfd_fops.c b/fs/trampfd/trampfd_fops.c
new file mode 100644
index 000000000000..7164dd4d9039
--- /dev/null
+++ b/fs/trampfd/trampfd_fops.c
@@ -0,0 +1,241 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Trampoline FD - System call and File operations.
+ *
+ * Author: Madhavan T. Venkataraman ([email protected])
+ *
+ * Copyright (C) 2020 Microsoft Corporation.
+ */
+
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/syscalls.h>
+#include <linux/seq_file.h>
+#include <linux/anon_inodes.h>
+#include <linux/trampfd.h>
+
+char *trampfd_name = "[trampfd]";
+
+struct kmem_cache *trampfd_cache;
+
+/*
+ * Arch stub function to return info for the trampfd syscall.
+ */
+int __attribute__((weak)) trampfd_arch(struct trampfd_info *info)
+{
+ return -EOPNOTSUPP;
+}
+
+/*
+ * Arch stub function to do arch specific initialization for a code
+ * descriptor.
+ */
+int __attribute__((weak)) trampfd_code_arch(struct trampfd_code *code)
+{
+ return -EOPNOTSUPP;
+}
+
+/*
+ * Arch stub function to do arch specific initialization for a data
+ * descriptor.
+ */
+int __attribute__((weak)) trampfd_data_arch(struct trampfd_data *data)
+{
+ return -EOPNOTSUPP;
+}
+
+#ifdef CONFIG_PROC_FS
+static void trampfd_show_fdinfo(struct seq_file *sfile, struct file *file)
+{
+ seq_puts(sfile, "Trampoline FD\n");
+}
+#endif
+
+static loff_t trampfd_llseek(struct file *file, loff_t offset, int whence)
+{
+ struct trampfd *trampfd = file->private_data;
+
+ if (whence != SEEK_SET)
+ return -EINVAL;
+
+ if ((offset < 0) || (offset >= TRAMPFD_NUM_OFFSETS))
+ return -EINVAL;
+
+ mutex_lock(&trampfd->lock);
+ if (offset != file->f_pos) {
+ file->f_pos = offset;
+ file->f_version = 0;
+ }
+ mutex_unlock(&trampfd->lock);
+ return offset;
+}
+
+int trampfd_code(struct file *file, const char __user *arg, size_t count)
+{
+ struct trampfd *trampfd = file->private_data;
+ struct trampfd_code code;
+ int rc = 0;
+
+ if (count != sizeof(code))
+ return -EINVAL;
+
+ if (copy_from_user(&code, arg, sizeof(code)))
+ return -EFAULT;
+
+ mutex_lock(&trampfd->lock);
+
+ if (trampfd->code) {
+ rc = -EEXIST;
+ goto unlock;
+ }
+
+ rc = trampfd_code_arch(&code);
+ if (rc)
+ goto unlock;
+
+ trampfd->code_reg = code.reg;
+ trampfd->ntrampolines = code.ntrampolines;
+ trampfd->code = (void *) (uintptr_t) code.table;
+unlock:
+ mutex_unlock(&trampfd->lock);
+ return rc;
+}
+
+int trampfd_data(struct file *file, const char __user *arg, size_t count)
+{
+ struct trampfd *trampfd = file->private_data;
+ struct trampfd_data data;
+ int rc = 0;
+
+ if (count != sizeof(data))
+ return -EINVAL;
+
+ if (copy_from_user(&data, arg, sizeof(data)))
+ return -EFAULT;
+
+ if (data.reserved)
+ return -EINVAL;
+
+ mutex_lock(&trampfd->lock);
+
+ if (trampfd->data) {
+ rc = -EEXIST;
+ goto unlock;
+ }
+
+ rc = trampfd_data_arch(&data);
+ if (rc)
+ goto unlock;
+
+ trampfd->data_reg = data.reg;
+ trampfd->data = (void *) (uintptr_t) data.table;
+unlock:
+ mutex_unlock(&trampfd->lock);
+ return rc;
+}
+
+static ssize_t trampfd_write(struct file *file, const char __user *arg,
+ size_t count, loff_t *ppos)
+{
+ int rc;
+
+ if (!arg || !count)
+ return -EINVAL;
+
+ switch (*ppos) {
+ case TRAMPFD_CODE:
+ rc = trampfd_code(file, arg, count);
+ break;
+
+ case TRAMPFD_DATA:
+ rc = trampfd_data(file, arg, count);
+ break;
+
+ default:
+ rc = -EINVAL;
+ goto out;
+ }
+out:
+ return rc ? rc : (ssize_t) count;
+}
+
+static int trampfd_release(struct inode *inode, struct file *file)
+{
+ struct trampfd *trampfd = file->private_data;
+
+ mutex_destroy(&trampfd->lock);
+ kmem_cache_free(trampfd_cache, trampfd);
+ return 0;
+}
+
+const struct file_operations trampfd_fops = {
+#ifdef CONFIG_PROC_FS
+ .show_fdinfo = trampfd_show_fdinfo,
+#endif
+ .llseek = trampfd_llseek,
+ .write = trampfd_write,
+ .release = trampfd_release,
+ .mmap = trampfd_mmap,
+ .get_unmapped_area = trampfd_get_unmapped_area,
+};
+
+SYSCALL_DEFINE1(trampfd, struct trampfd_info *, info_arg)
+{
+ struct trampfd *trampfd;
+ struct trampfd_info info;
+ struct file *file;
+ int fd;
+ int rc;
+
+ if (!trampfd_cache)
+ return -ENOMEM;
+
+ if (!info_arg)
+ return -EINVAL;
+
+ trampfd = kmem_cache_zalloc(trampfd_cache, GFP_KERNEL);
+ if (!trampfd)
+ return -ENOMEM;
+ mutex_init(&trampfd->lock);
+ trampfd->creator = current->pid;
+
+ trampfd_arch(&info);
+
+ if (copy_to_user(info_arg, &info, sizeof(info))) {
+ rc = -EFAULT;
+ goto freetramp;
+ }
+
+ rc = get_unused_fd_flags(O_CLOEXEC);
+ if (rc < 0)
+ goto freetramp;
+ fd = rc;
+
+ file = anon_inode_getfile(trampfd_name, &trampfd_fops, trampfd, O_RDWR);
+ if (IS_ERR(file)) {
+ rc = PTR_ERR(file);
+ goto freefd;
+ }
+ file->f_mode |= (FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE);
+
+ fd_install(fd, file);
+ return fd;
+freefd:
+ put_unused_fd(fd);
+freetramp:
+ kmem_cache_free(trampfd_cache, trampfd);
+ return rc;
+}
+
+int __init trampfd_feature_init(void)
+{
+ trampfd_cache = kmem_cache_create("trampfd_cache",
+ sizeof(struct trampfd), 0, SLAB_HWCACHE_ALIGN, NULL);
+ if (trampfd_cache == NULL) {
+ pr_warn("%s: kmem_cache_create failed", __func__);
+ return -ENOMEM;
+ }
+ return 0;
+}
+core_initcall(trampfd_feature_init);
diff --git a/fs/trampfd/trampfd_map.c b/fs/trampfd/trampfd_map.c
new file mode 100644
index 000000000000..679b29768491
--- /dev/null
+++ b/fs/trampfd/trampfd_map.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Trampoline FD - Memory mapping.
+ *
+ * Author: Madhavan T. Venkataraman ([email protected])
+ *
+ * Copyright (C) 2020 Microsoft Corporation.
+ */
+
+#include <linux/fs.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/mman.h>
+#include <linux/highmem.h>
+#include <linux/trampfd.h>
+
+/*
+ * Arch stub function to populate a page with trampolines based on a
+ * trampoline specification.
+ */
+void __attribute__((weak)) trampfd_code_fill(struct trampfd *trampfd,
+ char *addr)
+{
+}
+
+static void trampfd_close(struct vm_area_struct *vma)
+{
+ struct trampfd *trampfd = vma->vm_file->private_data;
+
+ mutex_lock(&trampfd->lock);
+
+ if (trampfd->page) {
+ __free_pages(trampfd->page, 0);
+ trampfd->page = NULL;
+ }
+ trampfd->mapped = false;
+
+ mutex_unlock(&trampfd->lock);
+}
+
+static vm_fault_t trampfd_fault(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct trampfd *trampfd = vma->vm_file->private_data;
+ struct page *new_page = NULL;
+ void *addr;
+
+ /*
+ * Check this outside the lock so the lock does not have to be
+ * dropped in order to allocate a page. Races are benign.
+ */
+ if (!trampfd->page) {
+ new_page = alloc_pages(GFP_KERNEL, 0);
+ if (!new_page)
+ return VM_FAULT_OOM;
+ }
+
+ mutex_lock(&trampfd->lock);
+
+ if (!trampfd->page) {
+ trampfd->page = new_page;
+ new_page = NULL;
+ /*
+ * Populate the page with trampolines.
+ */
+ addr = kmap(trampfd->page);
+ trampfd_code_fill(trampfd, addr);
+ kunmap(trampfd->page);
+ }
+ vmf->page = trampfd->page;
+ get_page(vmf->page);
+
+ mutex_unlock(&trampfd->lock);
+
+ if (new_page)
+ __free_pages(new_page, 0);
+ return 0;
+}
+
+static const struct vm_operations_struct trampfd_vm_ops = {
+ .close = trampfd_close,
+ .fault = trampfd_fault,
+};
+
+int trampfd_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ struct trampfd *trampfd = vma->vm_file->private_data;
+ int rc = 0;
+
+ /*
+ * A trampfd cannot be mapped into multiple address spaces.
+ */
+ if (current->pid != trampfd->creator)
+ return -EINVAL;
+
+ mutex_lock(&trampfd->lock);
+
+ /*
+ * trampfd must be initialized before it can be mapped.
+ */
+ if (!trampfd->code || !trampfd->data) {
+ rc = -EINVAL;
+ goto unlock;
+ }
+
+ /*
+ * A trampfd cannot be mapped multiple times in the same address space.
+ */
+ if (trampfd->mapped) {
+ rc = -EEXIST;
+ goto unlock;
+ }
+
+ /*
+ * prot should be R-X.
+ */
+ if ((vma->vm_flags & VM_WRITE) || !(vma->vm_flags & VM_READ) ||
+ !(vma->vm_flags & VM_EXEC)) {
+ rc = -EINVAL;
+ goto unlock;
+ }
+ trampfd->mapped = true;
+ vma->vm_ops = &trampfd_vm_ops;
+unlock:
+ mutex_unlock(&trampfd->lock);
+ return rc;
+}
+
+unsigned long
+trampfd_get_unmapped_area(struct file *file, unsigned long orig_addr,
+ unsigned long len, unsigned long pgoff,
+ unsigned long flags)
+{
+ const typeof_member(struct file_operations, get_unmapped_area)
+ get_area = current->mm->get_unmapped_area;
+
+ if (pgoff != TRAMPFD_CODE_PGOFF || flags != MAP_PRIVATE ||
+ len != PAGE_SIZE)
+ return -EINVAL;
+
+ return get_area(file, orig_addr, len, pgoff, flags);
+}
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index b951a87da987..91f55ff3cdac 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -69,6 +69,7 @@ union bpf_attr;
struct io_uring_params;
struct clone_args;
struct open_how;
+struct trampfd_info;
#include <linux/types.h>
#include <linux/aio_abi.h>
@@ -1005,6 +1006,7 @@ asmlinkage long sys_pidfd_send_signal(int pidfd, int sig,
siginfo_t __user *info,
unsigned int flags);
asmlinkage long sys_pidfd_getfd(int pidfd, int fd, unsigned int flags);
+asmlinkage long sys_trampfd(struct trampfd_info *info);
/*
* Architecture-specific system calls
diff --git a/include/linux/trampfd.h b/include/linux/trampfd.h
new file mode 100644
index 000000000000..c98fa1741c36
--- /dev/null
+++ b/include/linux/trampfd.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Trampoline FD - Internal structures and definitions.
+ *
+ * Author: Madhavan T. Venkataraman ([email protected])
+ *
+ * Copyright (c) 2020, Microsoft Corporation.
+ */
+#ifndef _LINUX_TRAMPFD_H
+#define _LINUX_TRAMPFD_H
+
+#include <uapi/linux/trampfd.h>
+
+/*
+ * mmap() offsets.
+ */
+enum trampfd_pgoff {
+ TRAMPFD_CODE_PGOFF = 1,
+ TRAMPFD_NUM_PGOFF,
+};
+
+/*
+ * Trampoline structure.
+ */
+struct trampfd {
+ struct mutex lock; /* to serialize access */
+ pid_t creator; /* to prevent sharing */
+
+ short code_reg; /* code register name */
+ short data_reg; /* data register name */
+ int ntrampolines; /* number of trampolines */
+
+ void *code; /* user code address table */
+ void *data; /* user data address table */
+
+ struct page *page; /* code page */
+ bool mapped; /* mapped into address space? */
+};
+
+#ifdef CONFIG_TRAMPFD
+
+int trampfd_mmap(struct file *file, struct vm_area_struct *vma);
+unsigned long trampfd_get_unmapped_area(struct file *file, unsigned long addr,
+ unsigned long len, unsigned long pgoff,
+ unsigned long flags);
+
+#endif /* CONFIG_TRAMPFD */
+
+#endif /* _LINUX_TRAMPFD_H */
diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
index f4a01305d9a6..3b1ad4b75c7a 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -857,9 +857,11 @@ __SYSCALL(__NR_openat2, sys_openat2)
__SYSCALL(__NR_pidfd_getfd, sys_pidfd_getfd)
#define __NR_faccessat2 439
__SYSCALL(__NR_faccessat2, sys_faccessat2)
+#define __NR_trampfd 440
+__SYSCALL(__NR_trampfd, sys_trampfd)
#undef __NR_syscalls
-#define __NR_syscalls 440
+#define __NR_syscalls 441
/*
* 32 bit systems traditionally used different
diff --git a/include/uapi/linux/trampfd.h b/include/uapi/linux/trampfd.h
new file mode 100644
index 000000000000..9bbc0450e16d
--- /dev/null
+++ b/include/uapi/linux/trampfd.h
@@ -0,0 +1,184 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Trampoline FD - API structures and definitions.
+ *
+ * Author: Madhavan T. Venkataraman ([email protected])
+ *
+ * Copyright (c) 2020, Microsoft Corporation.
+ */
+#ifndef _UAPI_LINUX_TRAMPFD_H
+#define _UAPI_LINUX_TRAMPFD_H
+
+#include <linux/types.h>
+#include <linux/ptrace.h>
+
+/*
+ * All structure fields are defined so that they are the same width and at the
+ * same structure offset on 32-bit and 64-bit to avoid compat code.
+ *
+ * All fields named "reserved" must be set to 0. They are there primarily for
+ * alignment. But they may be used in the future.
+ */
+
+/* ---------------------------- Trampfd Feature --------------------------- */
+
+/*
+ * This feature can be used to help convert dynamic user code to static user
+ * code so that the code can be in the text segment of a binary file. This
+ * allows the kernel to authenticate the code. E.g., using signature
+ * verification of the binary file.
+ *
+ * The problem in converting dynamic code to static code is that the static
+ * code needs to be able to locate its data dynamically. So, its data needs
+ * to be loaded in a designated register before jumping to the static code.
+ *
+ * This feature uses the kernel to generate a small, secure trampoline to do
+ * this. The trampoline code looks like this:
+ *
+ * - load the address of the static code in a register (code_reg)
+ * - load the address of its data in a register (data_reg)
+ * - jump to code_reg
+ *
+ * The kernel places the trampoline in a user page and maps it into the user
+ * address space. To conserve memory, the kernel packs multiple trampolines in
+ * a page and creates a trampoline table.
+ */
+
+/* -------------------------- Trampoline Creation ------------------------- */
+
+/*
+ * This feature introduces a new trampfd system call.
+ *
+ * struct trampfd_info info;
+ *
+ * trampfd = syscall(430, &info);
+ *
+ * The kernel returns the following items in info:
+ *
+ * ntrampolines
+ * The number of trampolines that can be created with one trampfd. The
+ * user may create fewer trampolines if he wishes.
+ *
+ * code_size
+ * The size of each trampoline.
+ *
+ * code_offset
+ * The file offset to be used in mmap() to map the trampoline code.
+ */
+struct trampfd_info {
+ __u32 ntrampolines;
+ __u32 code_size;
+ __u32 code_offset;
+ __u32 reserved;
+};
+
+/* ----------------------- Trampoline Initialization ---------------------- */
+
+/*
+ * Trampoline code descriptor.
+ *
+ * ntrampolines
+ * User specified number of trampolines. This number cannot exceed
+ * info.ntrampolines.
+ *
+ * reg
+ * User specified code register name. This is architecture specific and
+ * can be obtained from ptrace.h.
+ *
+ * table
+ * User array of code addresses, one address per trampoline.
+ *
+ */
+struct trampfd_code {
+ __u32 ntrampolines;
+ __u32 reg;
+ __u64 table;
+};
+
+/*
+ * Trampoline data descriptor.
+ *
+ * reg
+ * User specified data register name. This is architecture specific and
+ * can be obtained from ptrace.h.
+ *
+ * table
+ * User array of data addresses, one address per trampoline.
+ *
+ */
+struct trampfd_data {
+ __u32 reg;
+ __u32 reserved;
+ __u64 table;
+};
+
+/*
+ * A trampfd is initialized in this manner:
+ *
+ * struct trampfd_code code;
+ * struct trampfd_data data;
+ *
+ * code.ntrampolines = number of desired trampolines;
+ * code.reg = code register name;
+ * code.table = array of code addresses
+ *
+ * data.reg = data register name;
+ * data.table = array of data addresses
+ *
+ * pwrite(trampfd, &code, sizeof(init), TRAMPFD_CODE);
+ * pwrite(trampfd, &data, sizeof(init), TRAMPFD_DATA);
+ *
+ * It is recommended that the code descriptor and code array be placed in the
+ * .rodata section so that an attacker cannot modify its contents.
+ */
+
+/* ---------------------------- Trampoline mapping ------------------------ */
+
+/*
+ * The user uses mmap() to map the trampoline table into user address space.
+ *
+ * len = info.code_size * code.ntrampolines;
+ * prot = PROT_READ | PROT_EXEC;
+ * flags = MAP_PRIVATE;
+ * offset = info.code_offset;
+ *
+ * trampoline_table = mmap(NULL, len, prot, flags, trampfd, offset);
+ *
+ * The kernel generates the trampoline table. The code for trampoline X in the
+ * table is:
+ *
+ * load code_table[X] into code_reg
+ * load data_table[X] into data_reg
+ * jump code_reg
+ *
+ * The user manages the trampoline table. The address of trampoline X is:
+ *
+ * trampoline_table + info.code_size * X;
+ *
+ * Prior to invoking trampoline X, the user must initialize code_table[X] and
+ * data_table[X].
+ */
+
+/* ------------------------- Symbolic offsets -------------------------- */
+
+/*
+ * trampfd can have different actions/parameters associated with it. Each one
+ * has a symbolic file offset. Action/Parameter structures are read or written
+ * at their file offsets.
+ *
+ * Offset Operation Data
+ * ------------------------------------------------------------------------
+ * TRAMPFD_CODE Write struct trampfd_code
+ * TRAMPFD_DATA Write struct trampfd_data
+ * ------------------------------------------------------------------------
+ */
+enum trampfd_offsets {
+ TRAMPFD_CODE,
+ TRAMPFD_DATA,
+ TRAMPFD_NUM_OFFSETS,
+};
+
+
+/* ----------------------------------------------------------------------- */
+
+#endif /* _UAPI_LINUX_TRAMPFD_H */
diff --git a/init/Kconfig b/init/Kconfig
index 0498af567f70..bb3ecca5b8e7 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -2313,3 +2313,10 @@ config ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
# <asm/syscall_wrapper.h>.
config ARCH_HAS_SYSCALL_WRAPPER
def_bool n
+
+config TRAMPFD
+ bool "Enable trampfd() system call"
+ depends on MMU
+ help
+ Enable the trampfd() system call that allows a process to map
+ kernel generated trampolines within its address space.
diff --git a/kernel/sys_ni.c b/kernel/sys_ni.c
index 3b69a560a7ac..93c5972aba85 100644
--- a/kernel/sys_ni.c
+++ b/kernel/sys_ni.c
@@ -349,6 +349,9 @@ COND_SYSCALL(pkey_mprotect);
COND_SYSCALL(pkey_alloc);
COND_SYSCALL(pkey_free);
+/* Trampoline fd */
+COND_SYSCALL(trampfd);
+
/*
* Architecture specific weak syscall entries.
--
2.17.1
* madvenka:
> Examples of trampolines
> =======================
>
> libffi (A Portable Foreign Function Interface Library):
>
> libffi allows a user to define functions with an arbitrary list of
> arguments and return value through a feature called "Closures".
> Closures use trampolines to jump to ABI handlers that handle calling
> conventions and call a target function. libffi is used by a lot
> of different applications. To name a few:
>
> - Python
> - Java
> - Javascript
> - Ruby FFI
> - Lisp
> - Objective C
libffi does not actually need this. It currently collocates
trampolines and the data they need on the same page, but that's
actually unecessary. It's possible to avoid doing this just by
changing libffi, without any kernel changes.
I think this has already been done for the iOS port.
> The code for trampoline X in the trampoline table is:
>
> load &code_table[X], code_reg
> load (code_reg), code_reg
> load &data_table[X], data_reg
> load (data_reg), data_reg
> jump code_reg
>
> The addresses &code_table[X] and &data_table[X] are baked into the
> trampoline code. So, PC-relative data references are not needed. The user
> can modify code_table[X] and data_table[X] dynamically.
You can put this code into the libffi shared object and map it from
there, just like the rest of the libffi code. To get more
trampolines, you can map the page containing the trampolines multiple
times, each instance preceded by a separate data page with the control
information.
I think the previous patch submission has also resulted in several
comments along those lines, so I'm not sure why you are reposting
this.
> libffi
> ======
>
> I have implemented my solution for libffi and provided the changes for
> X86 and ARM, 32-bit and 64-bit. Here is the reference patch:
>
> http://linux.microsoft.com/~madvenka/libffi/libffi.v2.txt
The URL does not appear to work, I get a 403 error.
> If the trampfd patchset gets accepted, I will send the libffi changes
> to the maintainers for a review. BTW, I have also successfully executed
> the libffi self tests.
I have not seen your libffi changes, but I expect that the complexity
is about the same as a userspace-only solution.
Cc:ing libffi upstream for awareness. The start of the thread is
here:
<https://lore.kernel.org/linux-api/[email protected]/>
On 9/16/20 8:04 PM, Florian Weimer wrote:
> * madvenka:
>
>> Examples of trampolines
>> =======================
>>
>> libffi (A Portable Foreign Function Interface Library):
>>
>> libffi allows a user to define functions with an arbitrary list of
>> arguments and return value through a feature called "Closures".
>> Closures use trampolines to jump to ABI handlers that handle calling
>> conventions and call a target function. libffi is used by a lot
>> of different applications. To name a few:
>>
>> - Python
>> - Java
>> - Javascript
>> - Ruby FFI
>> - Lisp
>> - Objective C
>
> libffi does not actually need this. It currently collocates
> trampolines and the data they need on the same page, but that's
> actually unecessary. It's possible to avoid doing this just by
> changing libffi, without any kernel changes.
>
> I think this has already been done for the iOS port.
>
The trampoline table that has been implemented for the iOS port (MACH)
is based on PC-relative data referencing. That is, the code and data
are placed in adjacent pages so that the code can access the data using
an address relative to the current PC.
This is an ISA feature that is not supported on all architectures.
Now, if it is a performance feature, we can include some architectures
and exclude others. But this is a security feature. IMO, we cannot
exclude any architecture even if it is a legacy one as long as Linux
is running on the architecture. So, we need a solution that does
not assume any specific ISA feature.
>> The code for trampoline X in the trampoline table is:
>>
>> load &code_table[X], code_reg
>> load (code_reg), code_reg
>> load &data_table[X], data_reg
>> load (data_reg), data_reg
>> jump code_reg
>>
>> The addresses &code_table[X] and &data_table[X] are baked into the
>> trampoline code. So, PC-relative data references are not needed. The user
>> can modify code_table[X] and data_table[X] dynamically.
>
> You can put this code into the libffi shared object and map it from
> there, just like the rest of the libffi code. To get more
> trampolines, you can map the page containing the trampolines multiple
> times, each instance preceded by a separate data page with the control
> information.
>
If you put the code in the libffi shared object, how do you pass data to
the code at runtime? If the code we are talking about is a function, then
there is an ABI defined way to pass data to the function. But if the
code we are talking about is some arbitrary code such as a trampoline,
there is no ABI defined way to pass data to it except in a couple of
platforms such as HP PA-RISC that have support for function descriptors
in the ABI itself.
As mentioned before, if the ISA supports PC-relative data references
(e.g., X86 64-bit platforms support RIP-relative data references)
then we can pass data to that code by placing the code and data in
adjacent pages. So, you can implement the trampoline table for X64.
i386 does not support it.
> I think the previous patch submission has also resulted in several
> comments along those lines, so I'm not sure why you are reposting
> this.
IIRC, I have answered all of those comments by mentioning the point
that we need to support all architectures without requiring special
ISA features. Taking the kernel's help in this is one solution.
>
>> libffi
>> ======
>>
>> I have implemented my solution for libffi and provided the changes for
>> X86 and ARM, 32-bit and 64-bit. Here is the reference patch:
>>
>> http://linux.microsoft.com/~madvenka/libffi/libffi.v2.txt
>
> The URL does not appear to work, I get a 403 error.
I apologize for that. That site is supposed to be accessible publicly.
I will contact the administrator and get this resolved.
Sorry for the annoyance.
>
>> If the trampfd patchset gets accepted, I will send the libffi changes
>> to the maintainers for a review. BTW, I have also successfully executed
>> the libffi self tests.
>
> I have not seen your libffi changes, but I expect that the complexity
> is about the same as a userspace-only solution.
>
>
I agree. The complexity is about the same. But the support is for all
architectures. Once the common code is in place, the changes for each
architecture are trivial.
Madhavan
> Cc:ing libffi upstream for awareness. The start of the thread is
> here:
>
> <https://lore.kernel.org/linux-api/[email protected]/>
>
* Madhavan T. Venkataraman:
> On 9/17/20 10:36 AM, Madhavan T. Venkataraman wrote:
>>>> libffi
>>>> ======
>>>>
>>>> I have implemented my solution for libffi and provided the changes for
>>>> X86 and ARM, 32-bit and 64-bit. Here is the reference patch:
>>>>
>>>> http://linux.microsoft.com/~madvenka/libffi/libffi.v2.txt
>>> The URL does not appear to work, I get a 403 error.
>> I apologize for that. That site is supposed to be accessible publicly.
>> I will contact the administrator and get this resolved.
>>
>> Sorry for the annoyance.
> Could you try the link again and confirm that you can access it?
> Again, sorry for the trouble.
Yes, it works now. Thanks for having it fixed.
On 9/17/20 10:36 AM, Madhavan T. Venkataraman wrote:
>>> libffi
>>> ======
>>>
>>> I have implemented my solution for libffi and provided the changes for
>>> X86 and ARM, 32-bit and 64-bit. Here is the reference patch:
>>>
>>> http://linux.microsoft.com/~madvenka/libffi/libffi.v2.txt
>> The URL does not appear to work, I get a 403 error.
> I apologize for that. That site is supposed to be accessible publicly.
> I will contact the administrator and get this resolved.
>
> Sorry for the annoyance.
>
Could you try the link again and confirm that you can access it?
Again, sorry for the trouble.
Madhavan
On Thu, Sep 17, 2020 at 10:36:02AM -0500, Madhavan T. Venkataraman wrote:
>
>
> On 9/16/20 8:04 PM, Florian Weimer wrote:
> > * madvenka:
> >
> >> Examples of trampolines
> >> =======================
> >>
> >> libffi (A Portable Foreign Function Interface Library):
> >>
> >> libffi allows a user to define functions with an arbitrary list of
> >> arguments and return value through a feature called "Closures".
> >> Closures use trampolines to jump to ABI handlers that handle calling
> >> conventions and call a target function. libffi is used by a lot
> >> of different applications. To name a few:
> >>
> >> - Python
> >> - Java
> >> - Javascript
> >> - Ruby FFI
> >> - Lisp
> >> - Objective C
> >
> > libffi does not actually need this. It currently collocates
> > trampolines and the data they need on the same page, but that's
> > actually unecessary. It's possible to avoid doing this just by
> > changing libffi, without any kernel changes.
> >
> > I think this has already been done for the iOS port.
> >
>
> The trampoline table that has been implemented for the iOS port (MACH)
> is based on PC-relative data referencing. That is, the code and data
> are placed in adjacent pages so that the code can access the data using
> an address relative to the current PC.
>
> This is an ISA feature that is not supported on all architectures.
>
> Now, if it is a performance feature, we can include some architectures
> and exclude others. But this is a security feature. IMO, we cannot
> exclude any architecture even if it is a legacy one as long as Linux
> is running on the architecture. So, we need a solution that does
> not assume any specific ISA feature.
Which ISA does not support PIC objects? You mentioned i386 below, but
i386 does support them, it just needs to copy the PC into a GPR first
(see below).
>
> >> The code for trampoline X in the trampoline table is:
> >>
> >> load &code_table[X], code_reg
> >> load (code_reg), code_reg
> >> load &data_table[X], data_reg
> >> load (data_reg), data_reg
> >> jump code_reg
> >>
> >> The addresses &code_table[X] and &data_table[X] are baked into the
> >> trampoline code. So, PC-relative data references are not needed. The user
> >> can modify code_table[X] and data_table[X] dynamically.
> >
> > You can put this code into the libffi shared object and map it from
> > there, just like the rest of the libffi code. To get more
> > trampolines, you can map the page containing the trampolines multiple
> > times, each instance preceded by a separate data page with the control
> > information.
> >
>
> If you put the code in the libffi shared object, how do you pass data to
> the code at runtime? If the code we are talking about is a function, then
> there is an ABI defined way to pass data to the function. But if the
> code we are talking about is some arbitrary code such as a trampoline,
> there is no ABI defined way to pass data to it except in a couple of
> platforms such as HP PA-RISC that have support for function descriptors
> in the ABI itself.
>
> As mentioned before, if the ISA supports PC-relative data references
> (e.g., X86 64-bit platforms support RIP-relative data references)
> then we can pass data to that code by placing the code and data in
> adjacent pages. So, you can implement the trampoline table for X64.
> i386 does not support it.
>
i386 just needs a tiny bit of code to copy the PC into a GPR first, i.e.
the trampoline would be:
call 1f
1: pop %data_reg
movl (code_table + X - 1b)(%data_reg), %code_reg
movl (data_table + X - 1b)(%data_reg), %data_reg
jmp *(%code_reg)
I do not understand the point about passing data at runtime. This
trampoline is to achieve exactly that, no?
Thanks.
On Tue, Sep 22, 2020 at 09:46:16PM -0400, Arvind Sankar wrote:
> On Thu, Sep 17, 2020 at 10:36:02AM -0500, Madhavan T. Venkataraman wrote:
> >
> >
> > On 9/16/20 8:04 PM, Florian Weimer wrote:
> > > * madvenka:
> > >
> > >> Examples of trampolines
> > >> =======================
> > >>
> > >> libffi (A Portable Foreign Function Interface Library):
> > >>
> > >> libffi allows a user to define functions with an arbitrary list of
> > >> arguments and return value through a feature called "Closures".
> > >> Closures use trampolines to jump to ABI handlers that handle calling
> > >> conventions and call a target function. libffi is used by a lot
> > >> of different applications. To name a few:
> > >>
> > >> - Python
> > >> - Java
> > >> - Javascript
> > >> - Ruby FFI
> > >> - Lisp
> > >> - Objective C
> > >
> > > libffi does not actually need this. It currently collocates
> > > trampolines and the data they need on the same page, but that's
> > > actually unecessary. It's possible to avoid doing this just by
> > > changing libffi, without any kernel changes.
> > >
> > > I think this has already been done for the iOS port.
> > >
> >
> > The trampoline table that has been implemented for the iOS port (MACH)
> > is based on PC-relative data referencing. That is, the code and data
> > are placed in adjacent pages so that the code can access the data using
> > an address relative to the current PC.
> >
> > This is an ISA feature that is not supported on all architectures.
> >
> > Now, if it is a performance feature, we can include some architectures
> > and exclude others. But this is a security feature. IMO, we cannot
> > exclude any architecture even if it is a legacy one as long as Linux
> > is running on the architecture. So, we need a solution that does
> > not assume any specific ISA feature.
>
> Which ISA does not support PIC objects? You mentioned i386 below, but
> i386 does support them, it just needs to copy the PC into a GPR first
> (see below).
>
> >
> > >> The code for trampoline X in the trampoline table is:
> > >>
> > >> load &code_table[X], code_reg
> > >> load (code_reg), code_reg
> > >> load &data_table[X], data_reg
> > >> load (data_reg), data_reg
> > >> jump code_reg
> > >>
> > >> The addresses &code_table[X] and &data_table[X] are baked into the
> > >> trampoline code. So, PC-relative data references are not needed. The user
> > >> can modify code_table[X] and data_table[X] dynamically.
> > >
> > > You can put this code into the libffi shared object and map it from
> > > there, just like the rest of the libffi code. To get more
> > > trampolines, you can map the page containing the trampolines multiple
> > > times, each instance preceded by a separate data page with the control
> > > information.
> > >
> >
> > If you put the code in the libffi shared object, how do you pass data to
> > the code at runtime? If the code we are talking about is a function, then
> > there is an ABI defined way to pass data to the function. But if the
> > code we are talking about is some arbitrary code such as a trampoline,
> > there is no ABI defined way to pass data to it except in a couple of
> > platforms such as HP PA-RISC that have support for function descriptors
> > in the ABI itself.
> >
> > As mentioned before, if the ISA supports PC-relative data references
> > (e.g., X86 64-bit platforms support RIP-relative data references)
> > then we can pass data to that code by placing the code and data in
> > adjacent pages. So, you can implement the trampoline table for X64.
> > i386 does not support it.
> >
>
> i386 just needs a tiny bit of code to copy the PC into a GPR first, i.e.
> the trampoline would be:
>
> call 1f
> 1: pop %data_reg
> movl (code_table + X - 1b)(%data_reg), %code_reg
> movl (data_table + X - 1b)(%data_reg), %data_reg
> jmp *(%code_reg)
>
> I do not understand the point about passing data at runtime. This
> trampoline is to achieve exactly that, no?
>
> Thanks.
For libffi, I think the proposed standard trampoline won't actually
work, because not all ABIs have two scratch registers available to use
as code_reg and data_reg. Eg i386 fastcall only has one, and register
has zero scratch registers. I believe 32-bit ARM only has one scratch
register as well.
For i386 you'd need something that saves a register on the stack first,
maybe like the below with a 16-byte trampoline and a 16-byte context
structure that has the address of the code to jump to in the first
dword:
.balign 4096
trampoline_page:
.rept 4096/16-1
0: endbr32
push %eax
call __x86.get_pc_thunk.ax
1: jmp trampoline
.balign 16
.endr
.org trampoline_page + 4096 - 16
__x86.get_pc_thunk.ax:
movl (%esp), %eax
ret
trampoline:
subl $(1b-0b), %eax
jmp *(table-trampoline_page)(%eax)
.org trampoline_page + 4096
table:
On 9/23/20 4:11 AM, Arvind Sankar wrote:
> For libffi, I think the proposed standard trampoline won't actually
> work, because not all ABIs have two scratch registers available to use
> as code_reg and data_reg. Eg i386 fastcall only has one, and register
> has zero scratch registers. I believe 32-bit ARM only has one scratch
> register as well.
The trampoline is invoked as a function call in the libffi case. Any
caller saved register can be used as code_reg, can it not? And the
scratch register is needed only to jump to the code. After that, it
can be reused for any other purpose.
However, for ARM, you are quite correct. There is only one scratch
register. This means that I have to provide two types of trampolines:
- If an architecture has enough scratch registers, use the currently
defined trampoline.
- If the architecture has only one scratch register, but has PC-relative
data references, then embed the code address at the bottom of the
trampoline and access it using PC-relative addressing.
Thanks for pointing this out.
Madhavan
On Wed, Sep 23, 2020 at 02:17:30PM -0500, Madhavan T. Venkataraman wrote:
>
>
> On 9/23/20 4:11 AM, Arvind Sankar wrote:
> > For libffi, I think the proposed standard trampoline won't actually
> > work, because not all ABIs have two scratch registers available to use
> > as code_reg and data_reg. Eg i386 fastcall only has one, and register
> > has zero scratch registers. I believe 32-bit ARM only has one scratch
> > register as well.
>
> The trampoline is invoked as a function call in the libffi case. Any
> caller saved register can be used as code_reg, can it not? And the
> scratch register is needed only to jump to the code. After that, it
> can be reused for any other purpose.
>
> However, for ARM, you are quite correct. There is only one scratch
> register. This means that I have to provide two types of trampolines:
>
> - If an architecture has enough scratch registers, use the currently
> defined trampoline.
>
> - If the architecture has only one scratch register, but has PC-relative
> data references, then embed the code address at the bottom of the
> trampoline and access it using PC-relative addressing.
>
> Thanks for pointing this out.
>
> Madhavan
libffi is trying to provide closures with non-standard ABIs as well: the
actual user function is standard ABI, but the closure can be called with
a different ABI. If the closure was created with FFI_REGISTER abi, there
are no registers available for the trampoline to use: EAX, EDX and ECX
contain the first three arguments of the function, and every other
register is callee-save.
I provided a sample of the kind of trampoline that would be needed in
this case -- it's position-independent and doesn't clobber any registers
at all, and you get 255 trampolines per page. If I take another 16-byte
slot out of the page for the end trampoline that does the actual work,
I'm sure I could even come up with one that can just call a normal C
function, only the return might need special handling depending on the
return type.
And again, do you actually have any example of an architecture that
cannot run position-independent code? PC-relative addressing is an
implementation detail: the fact that it's available for x86_64 but not
for i386 just makes position-independent code more cumbersome on i386,
but it doesn't make it impossible. For the tiny trampolines here, it
makes almost no difference.
On 9/23/20 2:51 PM, Arvind Sankar wrote:
> On Wed, Sep 23, 2020 at 02:17:30PM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>> On 9/23/20 4:11 AM, Arvind Sankar wrote:
>>> For libffi, I think the proposed standard trampoline won't actually
>>> work, because not all ABIs have two scratch registers available to use
>>> as code_reg and data_reg. Eg i386 fastcall only has one, and register
>>> has zero scratch registers. I believe 32-bit ARM only has one scratch
>>> register as well.
>>
>> The trampoline is invoked as a function call in the libffi case. Any
>> caller saved register can be used as code_reg, can it not? And the
>> scratch register is needed only to jump to the code. After that, it
>> can be reused for any other purpose.
>>
>> However, for ARM, you are quite correct. There is only one scratch
>> register. This means that I have to provide two types of trampolines:
>>
>> - If an architecture has enough scratch registers, use the currently
>> defined trampoline.
>>
>> - If the architecture has only one scratch register, but has PC-relative
>> data references, then embed the code address at the bottom of the
>> trampoline and access it using PC-relative addressing.
>>
>> Thanks for pointing this out.
>>
>> Madhavan
>
> libffi is trying to provide closures with non-standard ABIs as well: the
> actual user function is standard ABI, but the closure can be called with
> a different ABI. If the closure was created with FFI_REGISTER abi, there
> are no registers available for the trampoline to use: EAX, EDX and ECX
> contain the first three arguments of the function, and every other
> register is callee-save.
>
> I provided a sample of the kind of trampoline that would be needed in
> this case -- it's position-independent and doesn't clobber any registers
> at all, and you get 255 trampolines per page. If I take another 16-byte
> slot out of the page for the end trampoline that does the actual work,
> I'm sure I could even come up with one that can just call a normal C
> function, only the return might need special handling depending on the
> return type.
>
> And again, do you actually have any example of an architecture that
> cannot run position-independent code? PC-relative addressing is an
> implementation detail: the fact that it's available for x86_64 but not
> for i386 just makes position-independent code more cumbersome on i386,
> but it doesn't make it impossible. For the tiny trampolines here, it
> makes almost no difference.
>
Hi Arvind,
I am preparing a response for all of your comments. I will send it out
tomorrow. Sorry for the delay.
Madhavan
On 9/23/20 2:51 PM, Arvind Sankar wrote:
> On Wed, Sep 23, 2020 at 02:17:30PM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>> On 9/23/20 4:11 AM, Arvind Sankar wrote:
>>> For libffi, I think the proposed standard trampoline won't actually
>>> work, because not all ABIs have two scratch registers available to use
>>> as code_reg and data_reg. Eg i386 fastcall only has one, and register
>>> has zero scratch registers. I believe 32-bit ARM only has one scratch
>>> register as well.
>>
>> The trampoline is invoked as a function call in the libffi case. Any
>> caller saved register can be used as code_reg, can it not? And the
>> scratch register is needed only to jump to the code. After that, it
>> can be reused for any other purpose.
>>
>> However, for ARM, you are quite correct. There is only one scratch
>> register. This means that I have to provide two types of trampolines:
>>
>> - If an architecture has enough scratch registers, use the currently
>> defined trampoline.
>>
>> - If the architecture has only one scratch register, but has PC-relative
>> data references, then embed the code address at the bottom of the
>> trampoline and access it using PC-relative addressing.
>>
>> Thanks for pointing this out.
>>
>> Madhavan
>
> libffi is trying to provide closures with non-standard ABIs as well: the
> actual user function is standard ABI, but the closure can be called with
> a different ABI. If the closure was created with FFI_REGISTER abi, there
> are no registers available for the trampoline to use: EAX, EDX and ECX
> contain the first three arguments of the function, and every other
> register is callee-save.
>
> I provided a sample of the kind of trampoline that would be needed in
> this case -- it's position-independent and doesn't clobber any registers
> at all, and you get 255 trampolines per page. If I take another 16-byte
> slot out of the page for the end trampoline that does the actual work,
> I'm sure I could even come up with one that can just call a normal C
> function, only the return might need special handling depending on the
> return type.
>
> And again, do you actually have any example of an architecture that
> cannot run position-independent code? PC-relative addressing is an
> implementation detail: the fact that it's available for x86_64 but not
> for i386 just makes position-independent code more cumbersome on i386,
> but it doesn't make it impossible. For the tiny trampolines here, it
> makes almost no difference.
>
I have tried to answer all of your previous comments here. Let me know
if I missed anything:
> Which ISA does not support PIC objects? You mentioned i386 below, but
> i386 does support them, it just needs to copy the PC into a GPR first
> (see below).
Position Independent Code needs PC-relative branches. I was referring
to PC-relative data references. Like RIP-relative data references in
X64. i386 ISA does not support this.
> i386 just needs a tiny bit of code to copy the PC into a GPR first, i.e.
> the trampoline would be:
>
> call 1f
> 1: pop %data_reg
> movl (code_table + X - 1b)(%data_reg), %code_reg
> movl (data_table + X - 1b)(%data_reg), %data_reg
> jmp *(%code_reg)
>
> I do not understand the point about passing data at runtime. This
> trampoline is to achieve exactly that, no?
PC-relative data referencing
----------------------------
I agree that the current PC value can be loaded in a GPR using the trick
of call, pop on i386.
Perhaps, on other architectures, we can do similar things. For instance,
in architectures that load the return address in a designated register
instead of pushing it on the stack, the trampoline could call a leaf function
that moves the value of that register into data_reg so that at the location
after the call instruction, the current PC is already loaded in data_reg.
SPARC is one example I can think of.
My take is - if the ISA supports PC-relative data referencing explicitly (like
X64 or ARM64), then we can use it. Or, if the ABI specification documents an
approved way to load the PC into a GPR, we can use it.
Otherwise, using an ABI quirk or a calling convention side effect to load the
PC into a GPR is, IMO, non-standard or non-compliant or non-approved or
whatever you want to call it. I would be conservative and not use it. Who knows
what incompatibility there will be with some future software or hardware
features?
For instance, in the i386 example, we do a call without a matching return.
Also, we use a pop to undo the call. Can anyone tell me if this kind of use
is an ABI approved one?
Kernel supplied trampoline
--------------------------
One advantage in doing this in the kernel is that we don't need to use
non-standard or non-ABI compliant code.
To minimize the number of registers used by the trampoline, I will redefine
the kernel generated trampoline as follows:
- The kernel loads the trampoline and the code and the data addresses to be
dereferenced like this:
A ----> -------------------
| Trampoline code |
B ----> -------------------
| Data Address |
-------------------
| Code Address |
-------------------
So, the trampoline code would be:
mov B, %data_reg
jump (%data_reg + sizeof(Data address))
The kernel will hard code B into the trampoline.
The static code that the trampoline jumps to looks like this:
load (%data_reg), %data_reg
rest of the code
Use of scratch registers
------------------------
With this new trampoline, we only use one scratch register. So, the same
RFC will work for libffi on ARM.
You pointed out that in the FFI_REGISTER ABI no scratch registers can
be used. Read the section "Secure vs Performant trampoline" below where
this is addressed.
Standard API for all userland for all architectures
---------------------------------------------------
The next advantage in using the kernel is standardization.
If the kernel supplies this, then all applications and libraries can use
it for all architectures with one single, simple API. Without this, each
application/library has to roll its own solution for every architecture-ABI
combo it wants to support.
Furthermore, if this work gets accepted, I plan to add a glibc wrapper for
the kernel API. The glibc API would look something like this:
Allocate a trampoline
---------------------
tramp = alloc_tramp();
Set trampoline parameters
-------------------------
init_tramp(tramp, code, data);
Free the trampoline
-------------------
free_tramp(tramp);
glibc will allocate and manage the code and data tables, handle kernel API
details and manage the trampoline table.
As an example, in libffi:
ffi_closure_alloc() would call alloc_tramp()
ffi_prep_closure_loc() would call init_tramp()
ffi_closure_free() would call free_tramp()
That is it! It works on all the architectures supported in the kernel for
trampfd.
This makes it really easy for maintainers to adopt the API and move their
code to a more secure model (which is the fundamental idea behind this work).
For this advantage alone, IMO, it is worth doing it in the kernel.
Secure vs Performant trampoline
-------------------------------
If you recall, in version 1, I presented a trampoline type that is
implemented in the kernel. When an application invokes the trampoline,
it traps into the kernel and the kernel performs the work of the trampoline.
The disadvantage is that a trip to the kernel is needed. That can be
expensive.
The advantage is that the kernel can add security checks before doing the
work. Mainly, I am looking at checks that might prevent the trampoline
from being used in an ROP/BOP chain. Some half-baked ideas:
- Check that the invocation is at the starting point of the
trampoline
- Check if the trampoline is jumping to an allowed PC
- Check if the trampoline is being invoked from an allowed
calling PC or PC range
Allowed PCs can be input using the trampfd API mentioned in version 1.
Basically, an array of PCs is written into trampfd.
Suggestions for other checks are most welcome!
I would like to implement an option in the trampfd API. The user can
choose a secure trampoline or a performant trampoline. For a performant
trampoline, the kernel will generate the code. For a secure trampoline,
the kernel will do the work itself.
In order to address the FFI_REGISTER ABI in libffi, we could use the secure
trampoline. In FFI_REGISTER, the data is pushed on the stack and the code
is jumped to without using any registers.
As outlined in version 1, the kernel can push the data address on the stack
and write the code address into the PC and return to userland.
For doing all of this, we need trampfd.
Permitting the use of trampfd
-----------------------------
An "exectramp" setting can be implemented in SELinux to selectively allow the
use of trampfd for applications.
Madhavan
* Madhavan T. Venkataraman:
> Otherwise, using an ABI quirk or a calling convention side effect to
> load the PC into a GPR is, IMO, non-standard or non-compliant or
> non-approved or whatever you want to call it. I would be
> conservative and not use it. Who knows what incompatibility there
> will be with some future software or hardware features?
AArch64 PAC makes a backwards-incompatible change that touches this
area, but we'll see if they can actually get away with it.
In general, these things are baked into the ABI, even if they are not
spelled out explicitly in the psABI supplement.
> For instance, in the i386 example, we do a call without a matching return.
> Also, we use a pop to undo the call. Can anyone tell me if this kind of use
> is an ABI approved one?
Yes, for i386, this is completely valid from an ABI point of view.
It's equally possible to use a regular function call and just read the
return address that has been pushed to the stack. Then there's no
stack mismatch at all. Return stack predictors (including the one
used by SHSTK) also recognize the CALL 0 construct, so that's fine as
well. The i386 psABI does not use function descriptors, and either
approach (out-of-line thunk or CALL 0) is in common use to materialize
the program counter in a register and construct the GOT pointer.
> If the kernel supplies this, then all applications and libraries can use
> it for all architectures with one single, simple API. Without this, each
> application/library has to roll its own solution for every architecture-ABI
> combo it wants to support.
Is there any other user for these type-generic trampolines?
Everything else I've seen generates machine code specific to the
function being called. libffi is quite the outlier in my experience
because the trampoline calls a generic data-driven
marshaller/unmarshaller. The other trampoline generators put this
marshalling code directly into the generated trampoline.
I'm still not convinced that this can't be done directly in libffi,
without kernel help. Hiding the architecture-specific code in the
kernel doesn't reduce overall system complexity.
> As an example, in libffi:
>
> ffi_closure_alloc() would call alloc_tramp()
>
> ffi_prep_closure_loc() would call init_tramp()
>
> ffi_closure_free() would call free_tramp()
>
> That is it! It works on all the architectures supported in the kernel for
> trampfd.
ffi_prep_closure_loc would still need to check whether the trampoline
has been allocated by alloc_tramp because some applications supply
their own (executable and writable) mapping. ffi_closure_alloc would
need to support different sizes (not matching the trampoline). It's
also unclear to me to what extent software out there writes to the
trampoline data directly, bypassing the libffi API (the structs are
not opaque, after all). And all the existing libffi memory management
code (including the embedded dlmalloc copy) would be needed to support
kernels without trampfd for years to come.
I very much agree that we have a gap in libffi when it comes to
JIT-less operation. But I'm not convinced that kernel support is
needed to close it, or that it is even the right design.
Hi!
> PC-relative data referencing
> ----------------------------
>
> I agree that the current PC value can be loaded in a GPR using the trick
> of call, pop on i386.
>
> Perhaps, on other architectures, we can do similar things. For instance,
> in architectures that load the return address in a designated register
> instead of pushing it on the stack, the trampoline could call a leaf function
> that moves the value of that register into data_reg so that at the location
> after the call instruction, the current PC is already loaded in data_reg.
> SPARC is one example I can think of.
>
> My take is - if the ISA supports PC-relative data referencing explicitly (like
> X64 or ARM64), then we can use it. Or, if the ABI specification documents an
> approved way to load the PC into a GPR, we can use it.
>
> Otherwise, using an ABI quirk or a calling convention side effect to load the
> PC into a GPR is, IMO, non-standard or non-compliant or non-approved or
> whatever you want to call it. I would be conservative and not use
ISAs are very well defined, and basically not changing. If you want to
argue we should not use something, you should have very clear picture
_why_ it is bad. "Non-standard or non-approved or whatever" just does
not cut it.
And yes, certain tricks may be seriously slow on modern CPUs, and we
might want to avoid those. But other than that... you should have
better argument than "it is non-standard".
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, Sep 24, 2020 at 03:23:52PM -0500, Madhavan T. Venkataraman wrote:
>
>
> > Which ISA does not support PIC objects? You mentioned i386 below, but
> > i386 does support them, it just needs to copy the PC into a GPR first
> > (see below).
>
> Position Independent Code needs PC-relative branches. I was referring
> to PC-relative data references. Like RIP-relative data references in
> X64. i386 ISA does not support this.
I was talking about PC-relative data references too: they are a
requirement for PIC code that wants to access any global data. They can
be implemented easily on i386 even though it doesn't have an addressing
mode that uses the PC.
> Otherwise, using an ABI quirk or a calling convention side effect to load the
> PC into a GPR is, IMO, non-standard or non-compliant or non-approved or
> whatever you want to call it. I would be conservative and not use it. Who knows
> what incompatibility there will be with some future software or hardware
> features?
>
> For instance, in the i386 example, we do a call without a matching return.
> Also, we use a pop to undo the call. Can anyone tell me if this kind of use
> is an ABI approved one?
This doesn't have anything to do with the ABI, since what happened here
isn't visible to any caller or callee. Any machine instruction sequence
that has the effect of copying the PC into a GPR is acceptable, but this
is basically the only possible solution on i386. If you don't like the
call/pop mismatch (though that's supported by the hardware, and is what
clang likes to use), you can use the slightly different technique used
in my example, which copies the top of stack into a GPR after a call.
This is how all i386 PIC code has always worked.
> Standard API for all userland for all architectures
> ---------------------------------------------------
>
> The next advantage in using the kernel is standardization.
>
> If the kernel supplies this, then all applications and libraries can use
> it for all architectures with one single, simple API. Without this, each
> application/library has to roll its own solution for every architecture-ABI
> combo it wants to support.
But you can get even more standardization out of a userspace library,
because that can work even on non-linux OS's, as well as versions of
linux where the new syscall isn't available.
>
> Furthermore, if this work gets accepted, I plan to add a glibc wrapper for
> the kernel API. The glibc API would look something like this:
>
> Allocate a trampoline
> ---------------------
>
> tramp = alloc_tramp();
>
> Set trampoline parameters
> -------------------------
>
> init_tramp(tramp, code, data);
>
> Free the trampoline
> -------------------
>
> free_tramp(tramp);
>
> glibc will allocate and manage the code and data tables, handle kernel API
> details and manage the trampoline table.
glibc could do this already if it wants, even without the syscall,
because this can be done in userspace already.
>
> Secure vs Performant trampoline
> -------------------------------
>
> If you recall, in version 1, I presented a trampoline type that is
> implemented in the kernel. When an application invokes the trampoline,
> it traps into the kernel and the kernel performs the work of the trampoline.
>
> The disadvantage is that a trip to the kernel is needed. That can be
> expensive.
>
> The advantage is that the kernel can add security checks before doing the
> work. Mainly, I am looking at checks that might prevent the trampoline
> from being used in an ROP/BOP chain. Some half-baked ideas:
>
> - Check that the invocation is at the starting point of the
> trampoline
>
> - Check if the trampoline is jumping to an allowed PC
>
> - Check if the trampoline is being invoked from an allowed
> calling PC or PC range
>
> Allowed PCs can be input using the trampfd API mentioned in version 1.
> Basically, an array of PCs is written into trampfd.
The source PC will generally not be available if the compiler decided to
tail-call optimize the call to the trampoline into a jump.
What's special about these trampolines anyway? Any indirect function
call could have these same problems -- an attacker could have
overwritten the pointer the same way, whether it's supposed to point to
a normal function or it is the target of this trampoline.
For making them a bit safer, userspace could just map the page holding
the data pointers/destination address(es) as read-only after
initialization.
>
> Suggestions for other checks are most welcome!
>
> I would like to implement an option in the trampfd API. The user can
> choose a secure trampoline or a performant trampoline. For a performant
> trampoline, the kernel will generate the code. For a secure trampoline,
> the kernel will do the work itself.
>
> In order to address the FFI_REGISTER ABI in libffi, we could use the secure
> trampoline. In FFI_REGISTER, the data is pushed on the stack and the code
> is jumped to without using any registers.
>
> As outlined in version 1, the kernel can push the data address on the stack
> and write the code address into the PC and return to userland.
>
> For doing all of this, we need trampfd.
We don't need this for FFI_REGISTER. I presented a solution that works
in userspace. Even if you want to use a trampoline created by the
kernel, there's no reason it needs to trap into the kernel at trampoline
execution time. libffi's trampolines already handle this case today.
>
> Permitting the use of trampfd
> -----------------------------
>
> An "exectramp" setting can be implemented in SELinux to selectively allow the
> use of trampfd for applications.
>
> Madhavan
Applications can use their own userspace trampolines regardless of this
setting, so it doesn't provide any additional security benefit by
preventing usage of trampfd.
On 9/24/20 3:52 PM, Florian Weimer wrote:
> * Madhavan T. Venkataraman:
>
>> Otherwise, using an ABI quirk or a calling convention side effect to
>> load the PC into a GPR is, IMO, non-standard or non-compliant or
>> non-approved or whatever you want to call it. I would be
>> conservative and not use it. Who knows what incompatibility there
>> will be with some future software or hardware features?
>
> AArch64 PAC makes a backwards-incompatible change that touches this
> area, but we'll see if they can actually get away with it.
>
> In general, these things are baked into the ABI, even if they are not
> spelled out explicitly in the psABI supplement.
>
>> For instance, in the i386 example, we do a call without a matching return.
>> Also, we use a pop to undo the call. Can anyone tell me if this kind of use
>> is an ABI approved one?
>
> Yes, for i386, this is completely valid from an ABI point of view.
> It's equally possible to use a regular function call and just read the
> return address that has been pushed to the stack. Then there's no
> stack mismatch at all. Return stack predictors (including the one
> used by SHSTK) also recognize the CALL 0 construct, so that's fine as
> well. The i386 psABI does not use function descriptors, and either
> approach (out-of-line thunk or CALL 0) is in common use to materialize
> the program counter in a register and construct the GOT pointer.
>
>> If the kernel supplies this, then all applications and libraries can use
>> it for all architectures with one single, simple API. Without this, each
>> application/library has to roll its own solution for every architecture-ABI
>> combo it wants to support.
>
> Is there any other user for these type-generic trampolines?
> Everything else I've seen generates machine code specific to the
> function being called. libffi is quite the outlier in my experience
> because the trampoline calls a generic data-driven
> marshaller/unmarshaller. The other trampoline generators put this
> marshalling code directly into the generated trampoline.
>
> I'm still not convinced that this can't be done directly in libffi,
> without kernel help. Hiding the architecture-specific code in the
> kernel doesn't reduce overall system complexity.
>
See below. I have accepted the community's recommendation to implement it
in user land. However, this is not just for libffi. It is for all dynamic
code. libffi is just the first use case I am addressing with this.
>> As an example, in libffi:
>>
>> ffi_closure_alloc() would call alloc_tramp()
>>
>> ffi_prep_closure_loc() would call init_tramp()
>>
>> ffi_closure_free() would call free_tramp()
>>
>> That is it! It works on all the architectures supported in the kernel for
>> trampfd.
>
> ffi_prep_closure_loc would still need to check whether the trampoline
> has been allocated by alloc_tramp because some applications supply
> their own (executable and writable) mapping. ffi_closure_alloc would
> need to support different sizes (not matching the trampoline). It's
> also unclear to me to what extent software out there writes to the
> trampoline data directly, bypassing the libffi API (the structs are
> not opaque, after all). And all the existing libffi memory management
> code (including the embedded dlmalloc copy) would be needed to support
> kernels without trampfd for years to come.
>
In the libffi patch I have included, I have handled this. The closure
structure contains a tramp field:
char tramp[FFI_TRAMPOLINE_SIZE];
If trampfd is not used, this array will contain the actual
trampoline code. If trampfd is used, then we don't need the array for
storing any trampoline code. That space can be used for storing trampfd
related information.
So, there is no change to the closure structure.
Also, the code can tell if the closure has been allocated from dlmalloc()
called from ffi_closure_alloc() or has been allocated by the caller
directly without calling ffi_closure_alloc(). I have written this function:
int ffi_closure_alloc_called(void *closure)
{
msegmentptr seg = segment_holding (gm, closure);
return (seg != NULL);
}
Using this function, I can tell how the closure has been allocated. I use
trampfd only for closures that have been allocated using ffi_closure_alloc().
So, I believe I have handled all the cases. If I have missed anything,
let me know. I will address it.
> I very much agree that we have a gap in libffi when it comes to
> JIT-less operation. But I'm not convinced that kernel support is
> needed to close it, or that it is even the right design.
>
I have taken into account most of the comments received so far and I have
come up with a proposal:
I would like to do this in two separate RFCs:
library RFC
-----------
I accept the recommendation of the reviewers about implementing it in
user land in a library.
Just for the sake of context, I would like to reiterate the problem being
solved and what the library will contain. Bear with me.
My goal is to help convert existing dynamic code to static code as far as
possible. The binary generated from the static code can be signed. The
kernel can use signature verification to authenticate the code. This way,
we don't need to disable W^X or make exceptions for the code (exemem etc) or
use any user level methods to somehow map and execute the code.
The dynamic code can be very simple like the libffi trampoline. Or, it can
be a lot more complex. E.g., a trampoline that uses data marshaling as Florian
mentioned. In all cases, when the code is converted to static code, the static
code needs to know where its data will be located at runtime. If static code is
a function, then one can just pass parameters. But if it is arbitrary code,
then one needs a way to inform the static code where it can find its data.
The code can use PC-relative referencing where available. For the sake of this
discussion, let us assume that we can use some trick or the other to load the
current PC into a GPR on all architectures. Then, we can use PC-relative
referencing. Let us assume that these tricks will not cause ABI compliance
issues in the future.
The maintainer of the dynamic code who wishes to convert it to static code
should not have to deal with all of these details. The static code should
be able to assume that its data is pointed to by a designated register. Or,
it should be able to assume that the data pointer has been pushed on the
stack. Then, it is easier for maintainers to adopt this and move their code
to a more secure model.
This can be achieved by providing a small, minimal trampoline that loads the
data pointer in a register or pushes it on the stack and jumps to the static
code.
The reviewers felt that the minimal trampoline can be provided in user land.
So, I will provide a user library. The user library will:
- define the minimal trampoline statically for different architectures
using some flavor of PC-relative data referencing
- provide a table of trampolines in a page
- create and manage code and data pages
- present a simple API to dynamic code maintainers
This overall approach has pretty much been agreed upon by the community so
far. I will send out an RFC for the library once I have the code ready.
Which library?
--------------
I need a recommendation from the community on this. Should I just place the
code in glibc? Or, should I create a libtramp for this? I prefer glibc as
it will make for easier adoption. But I will defer to the community on this.
What do you recommend?
trampfd RFC version 3
---------------------
Once the library RFC is accepted, I would, however, like to submit
version 3 of trampfd.
The library would support a choice of trampoline:
- fast user trampoline described above
- slow kernel trampoline described below that supports security
checks each time the trampoline is invoked
The minimal trampoline mentioned above would also be implemented in the
kernel. The mechanism is outlined in version 1. When the application executes
the trampoline, it would trap into the kernel and the kernel would do the
work (load the data pointer in a user register or push it on the user stack and set
the user PC to the target code and return). The kernel will perform security checks when
the trampoline is invoked. For instance, to reduce or eliminate the possibility
of the trampoline being used in an ROP/BOP chain. The checks are work in
progress. But I think I can nail them.
Note that there is no code generation involved in this proposal. The kernel
is the trampoline.
Would you guys be willing to consider this approach?
Madhavan
On 9/24/20 6:43 PM, Arvind Sankar wrote:
> On Thu, Sep 24, 2020 at 03:23:52PM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>>> Which ISA does not support PIC objects? You mentioned i386 below, but
>>> i386 does support them, it just needs to copy the PC into a GPR first
>>> (see below).
>>
>> Position Independent Code needs PC-relative branches. I was referring
>> to PC-relative data references. Like RIP-relative data references in
>> X64. i386 ISA does not support this.
>
> I was talking about PC-relative data references too: they are a
> requirement for PIC code that wants to access any global data. They can
> be implemented easily on i386 even though it doesn't have an addressing
> mode that uses the PC.
>
>> Otherwise, using an ABI quirk or a calling convention side effect to load the
>> PC into a GPR is, IMO, non-standard or non-compliant or non-approved or
>> whatever you want to call it. I would be conservative and not use it. Who knows
>> what incompatibility there will be with some future software or hardware
>> features?
>>
>> For instance, in the i386 example, we do a call without a matching return.
>> Also, we use a pop to undo the call. Can anyone tell me if this kind of use
>> is an ABI approved one?
>
> This doesn't have anything to do with the ABI, since what happened here
> isn't visible to any caller or callee. Any machine instruction sequence
> that has the effect of copying the PC into a GPR is acceptable, but this
> is basically the only possible solution on i386. If you don't like the
> call/pop mismatch (though that's supported by the hardware, and is what
> clang likes to use), you can use the slightly different technique used
> in my example, which copies the top of stack into a GPR after a call.
>
> This is how all i386 PIC code has always worked.
>
I have responded to this in my reply to Florian. Basically, I accept the opinion
of the reviewers. I will assume that any trick we use to get the current PC into a
GPR will not cause ABI compliance issue in the future.
>> Standard API for all userland for all architectures
>> ---------------------------------------------------
>>
>> The next advantage in using the kernel is standardization.
>>
>> If the kernel supplies this, then all applications and libraries can use
>> it for all architectures with one single, simple API. Without this, each
>> application/library has to roll its own solution for every architecture-ABI
>> combo it wants to support.
>
> But you can get even more standardization out of a userspace library,
> because that can work even on non-linux OS's, as well as versions of
> linux where the new syscall isn't available.
>
Dealing with old vs new kernels is the same as dealing with old vs new libs.
In any case, what you have suggested above has already been suggested before
and I have accepted everyone's opinion. Please see my response to Florian's email.
>>
>> Furthermore, if this work gets accepted, I plan to add a glibc wrapper for
>> the kernel API. The glibc API would look something like this:
>>
>> Allocate a trampoline
>> ---------------------
>>
>> tramp = alloc_tramp();
>>
>> Set trampoline parameters
>> -------------------------
>>
>> init_tramp(tramp, code, data);
>>
>> Free the trampoline
>> -------------------
>>
>> free_tramp(tramp);
>>
>> glibc will allocate and manage the code and data tables, handle kernel API
>> details and manage the trampoline table.
>
> glibc could do this already if it wants, even without the syscall,
> because this can be done in userspace already.
>
I am wary of using ABI tricks or calling convention side-effects. However,
since the reviewers feel it is OK, I have accepted that opinion. I have
assumed now that any trick to load the current PC into a GPR can be used
without any risk. I hope that assumption is correct.
>>
>> Secure vs Performant trampoline
>> -------------------------------
>>
>> If you recall, in version 1, I presented a trampoline type that is
>> implemented in the kernel. When an application invokes the trampoline,
>> it traps into the kernel and the kernel performs the work of the trampoline.
>>
>> The disadvantage is that a trip to the kernel is needed. That can be
>> expensive.
>>
>> The advantage is that the kernel can add security checks before doing the
>> work. Mainly, I am looking at checks that might prevent the trampoline
>> from being used in an ROP/BOP chain. Some half-baked ideas:
>>
>> - Check that the invocation is at the starting point of the
>> trampoline
>>
>> - Check if the trampoline is jumping to an allowed PC
>>
>> - Check if the trampoline is being invoked from an allowed
>> calling PC or PC range
>>
>> Allowed PCs can be input using the trampfd API mentioned in version 1.
>> Basically, an array of PCs is written into trampfd.
>
> The source PC will generally not be available if the compiler decided to
> tail-call optimize the call to the trampoline into a jump.
>
This is still work in progress. But I am thinking that labels can be used.
So, if the code is:
invoke_tramp:
(*tramp)();
then, invoke_tramp can be supplied as the calling PC.
Similarly, labels can be used in assembly functions as well.
Like I said, I have to think about this more.
> What's special about these trampolines anyway? Any indirect function
> call could have these same problems -- an attacker could have
> overwritten the pointer the same way, whether it's supposed to point to
> a normal function or it is the target of this trampoline.
>
> For making them a bit safer, userspace could just map the page holding
> the data pointers/destination address(es) as read-only after
> initialization.
>
You need to look at version 1 of trampfd for how to do "allowed pcs".
As an example, libffi defines ABI handlers for every arch-ABI combo.
These ABI handler pointers could be placed in an array in .rodata.
Then, the array can be written into trampfd for setting allowed PCS.
When the target PC is set for a trampoline, the kernel will check
it against allowed PCs and reject it if it has been overwritten.
>>
>> Suggestions for other checks are most welcome!
>>
>> I would like to implement an option in the trampfd API. The user can
>> choose a secure trampoline or a performant trampoline. For a performant
>> trampoline, the kernel will generate the code. For a secure trampoline,
>> the kernel will do the work itself.
>>
>> In order to address the FFI_REGISTER ABI in libffi, we could use the secure
>> trampoline. In FFI_REGISTER, the data is pushed on the stack and the code
>> is jumped to without using any registers.
>>
>> As outlined in version 1, the kernel can push the data address on the stack
>> and write the code address into the PC and return to userland.
>>
>> For doing all of this, we need trampfd.
>
> We don't need this for FFI_REGISTER. I presented a solution that works
> in userspace. Even if you want to use a trampoline created by the
> kernel, there's no reason it needs to trap into the kernel at trampoline
> execution time. libffi's trampolines already handle this case today.
>
libffi handles this using user level dynamic code which needs to be executed.
If the security subsystem prevents that, then the dynamic code cannot execute.
That is the whole point of this RFC.
>>
>> Permitting the use of trampfd
>> -----------------------------
>>
>> An "exectramp" setting can be implemented in SELinux to selectively allow the
>> use of trampfd for applications.
>>
>> Madhavan
>
> Applications can use their own userspace trampolines regardless of this
> setting, so it doesn't provide any additional security benefit by
> preventing usage of trampfd.
>
The background for all of this is that dynamic code such as trampolines
need to be placed in a page with executable permissions so they can
execute. If security measures such as W^X are present, this will not
be possible. Admitted, today some user level tricks exist to get around
W^X. I have alluded to those. IMO, they are all security holes and will
get plugged sooner or later. Then, these trampolines cannot execute.
Currently, there exist security exceptions such as execmem to let them
execute. But we would like to do it without making security exceptions.
Madhavan
On Fri, Sep 25, 2020 at 05:44:56PM -0500, Madhavan T. Venkataraman wrote:
>
>
> On 9/24/20 6:43 PM, Arvind Sankar wrote:
> >
> > The source PC will generally not be available if the compiler decided to
> > tail-call optimize the call to the trampoline into a jump.
> >
>
> This is still work in progress. But I am thinking that labels can be used.
> So, if the code is:
>
> invoke_tramp:
> (*tramp)();
>
> then, invoke_tramp can be supplied as the calling PC.
>
> Similarly, labels can be used in assembly functions as well.
>
> Like I said, I have to think about this more.
What I mean is that the kernel won't have access to the actual source
PC. If I followed your v1 correctly, it works by making any branch to
the trampoline code trigger a page fault. At this point, the PC has
already been updated to the trampoline entry, so the only thing the
fault handler can know is the return address on the top of the stack,
which (a) might not be where the branch actually originated, either
because it was a jump, or you've already been hacked and you got here
using a ret; (b) is available to userspace anyway.
>
> > What's special about these trampolines anyway? Any indirect function
> > call could have these same problems -- an attacker could have
> > overwritten the pointer the same way, whether it's supposed to point to
> > a normal function or it is the target of this trampoline.
> >
> > For making them a bit safer, userspace could just map the page holding
> > the data pointers/destination address(es) as read-only after
> > initialization.
> >
>
> You need to look at version 1 of trampfd for how to do "allowed pcs".
> As an example, libffi defines ABI handlers for every arch-ABI combo.
> These ABI handler pointers could be placed in an array in .rodata.
> Then, the array can be written into trampfd for setting allowed PCS.
> When the target PC is set for a trampoline, the kernel will check
> it against allowed PCs and reject it if it has been overwritten.
I'm not asking how it's implemented. I'm asking what's the point? On a
typical linux system, at least on x86, every library function call is an
indirect branch. The protection they get is that the dynamic linker can
map the pointer table read-only after initializing it.
For the RO mapping, libffi could be mapping both the entire closure
structure, as well as the structure that describes the arguments and
return types of the function, read-only once they are initialized.
For libffi, there are three indirect branches for every trampoline call
with your suggested trampoline: one to get to the trampoline, one to
jump to the handler, and one to call the actual user function. If we are
particularly concerned about the trampoline to handler branch for some
reason, we could just replace it with a direct branch: if the kernel was
generating the code, there's no reason to allow the data pointer or code
target to be changed after the trampoline was created. It can just
hard-code them in the generated code and be done with it. Even with
user-space trampolines, you can use a direct call. All you need is
libffi-trampoline.so which contains a few thousand trampolines all
jumping to one handler, which then decides what to do based on which
trampoline was called. Sure libffi currently dispatches to one of 2-3
handlers based on the ABI, but there's no technical reason it couldn't
dispatch to just one that handled all the ABIs, and the trampoline could
be boiled down to just:
endbr
call handler
ret
> >>
> >> In order to address the FFI_REGISTER ABI in libffi, we could use the secure
> >> trampoline. In FFI_REGISTER, the data is pushed on the stack and the code
> >> is jumped to without using any registers.
> >>
> >> As outlined in version 1, the kernel can push the data address on the stack
> >> and write the code address into the PC and return to userland.
> >>
> >> For doing all of this, we need trampfd.
> >
> > We don't need this for FFI_REGISTER. I presented a solution that works
> > in userspace. Even if you want to use a trampoline created by the
> > kernel, there's no reason it needs to trap into the kernel at trampoline
> > execution time. libffi's trampolines already handle this case today.
> >
>
> libffi handles this using user level dynamic code which needs to be executed.
> If the security subsystem prevents that, then the dynamic code cannot execute.
> That is the whole point of this RFC.
/If/ you are using a trampoline created by the kernel, it can just
create the one that libffi is using today; which doesn't need trapping
into the kernel at execution time.
And if you aren't, you can use the trampoline I wrote, which has no
dynamic code, and doesn't need to trap into the kernel at execution time
either.
>
> >>
> >> Permitting the use of trampfd
> >> -----------------------------
> >>
> >> An "exectramp" setting can be implemented in SELinux to selectively allow the
> >> use of trampfd for applications.
> >>
> >> Madhavan
> >
> > Applications can use their own userspace trampolines regardless of this
> > setting, so it doesn't provide any additional security benefit by
> > preventing usage of trampfd.
> >
>
> The background for all of this is that dynamic code such as trampolines
> need to be placed in a page with executable permissions so they can
> execute. If security measures such as W^X are present, this will not
> be possible. Admitted, today some user level tricks exist to get around
> W^X. I have alluded to those. IMO, they are all security holes and will
> get plugged sooner or later. Then, these trampolines cannot execute.
> Currently, there exist security exceptions such as execmem to let them
> execute. But we would like to do it without making security exceptions.
>
> Madhavan
How can you still say this after this whole discussion? Applications can
get the exact same functionality as your proposed trampfd using static
code, no W^X tricks needed.
This only matters if you have a trampfd that generates _truly_ dynamic
code, not just code that can be trivially made static.
On 9/26/20 10:55 AM, Arvind Sankar wrote:
> On Fri, Sep 25, 2020 at 05:44:56PM -0500, Madhavan T. Venkataraman wrote:
>>
>>
>> On 9/24/20 6:43 PM, Arvind Sankar wrote:
>>>
>>> The source PC will generally not be available if the compiler decided to
>>> tail-call optimize the call to the trampoline into a jump.
>>>
>>
>> This is still work in progress. But I am thinking that labels can be used.
>> So, if the code is:
>>
>> invoke_tramp:
>> (*tramp)();
>>
>> then, invoke_tramp can be supplied as the calling PC.
>>
>> Similarly, labels can be used in assembly functions as well.
>>
>> Like I said, I have to think about this more.
>
> What I mean is that the kernel won't have access to the actual source
> PC. If I followed your v1 correctly, it works by making any branch to
> the trampoline code trigger a page fault. At this point, the PC has
> already been updated to the trampoline entry, so the only thing the
> fault handler can know is the return address on the top of the stack,
> which (a) might not be where the branch actually originated, either
> because it was a jump, or you've already been hacked and you got here
> using a ret; (b) is available to userspace anyway.
Like I said, this is work in progress. I have to spend time to figure out
how this would work or if this would work. So, let us brainstorm this
a little bit.
There are two ways to invoke the trampoline:
(1) By just branching to the trampoline address.
(2) Or, by treating the address as a function pointer and calling it.
In the libffi case, it is (2).
If it is (2), it is easier. We can figure out the return address of the
call which would be the location after the call instruction.
If it is (1), it is harder as you point out. So, we can support this
at least for (2). The user can inform trampfd as to the type of
invocation for the trampoline.
For (1), the return address would be that of the call to the function
that contains the branch. If the kernel can get that call instruction
and figure out the function address, then we can do something.
I admit this is bit hairy at the moment. I have to work it out.
>
>>
>>> What's special about these trampolines anyway? Any indirect function
>>> call could have these same problems -- an attacker could have
>>> overwritten the pointer the same way, whether it's supposed to point to
>>> a normal function or it is the target of this trampoline.
>>>
>>> For making them a bit safer, userspace could just map the page holding
>>> the data pointers/destination address(es) as read-only after
>>> initialization.
>>>
>>
>> You need to look at version 1 of trampfd for how to do "allowed pcs".
>> As an example, libffi defines ABI handlers for every arch-ABI combo.
>> These ABI handler pointers could be placed in an array in .rodata.
>> Then, the array can be written into trampfd for setting allowed PCS.
>> When the target PC is set for a trampoline, the kernel will check
>> it against allowed PCs and reject it if it has been overwritten.
>
> I'm not asking how it's implemented. I'm asking what's the point? On a
> typical linux system, at least on x86, every library function call is an
> indirect branch. The protection they get is that the dynamic linker can
> map the pointer table read-only after initializing it.
>
The security subsystem is concerned about dynamic code, not the indirect
branches set up for dynamic linking.
> For the RO mapping, libffi could be mapping both the entire closure
> structure, as well as the structure that describes the arguments and
> return types of the function, read-only once they are initialized.
>
This has been suggested in some form before. The general problem with
this approach is that when the page is still writable, an attacker
can inject his code potentially. Making the page read-only after the
fact may not help. In specific use cases, it may work. But it is
not OK as a general approach to solving this problem.
> For libffi, there are three indirect branches for every trampoline call
> with your suggested trampoline: one to get to the trampoline, one to
> jump to the handler, and one to call the actual user function. If we are
> particularly concerned about the trampoline to handler branch for some
> reason, we could just replace it with a direct branch: if the kernel was
> generating the code, there's no reason to allow the data pointer or code
> target to be changed after the trampoline was created. It can just
> hard-code them in the generated code and be done with it. Even with
> user-space trampolines, you can use a direct call. All you need is
> libffi-trampoline.so which contains a few thousand trampolines all
> jumping to one handler, which then decides what to do based on which
> trampoline was called. Sure libffi currently dispatches to one of 2-3
> handlers based on the ABI, but there's no technical reason it couldn't
> dispatch to just one that handled all the ABIs, and the trampoline could
> be boiled down to just:
> endbr
> call handler
> ret
>
One still needs this trampoline:
load closure in some register
jump to single_handler
In the kernel based solution, the user would specify to the kernel the
target PC in a code context.
pwrite(trampfd, code_context, size, CODE_OFFSET);
code_context itself can be hacked unless it is in .rodata. The allowed_pcs
thing exists for apps/libs that are unable or unwilling to place code_context
in .rodata.
I would like to not just focus how to solve things for libffi alone.
>>>>
>>>> In order to address the FFI_REGISTER ABI in libffi, we could use the secure
>>>> trampoline. In FFI_REGISTER, the data is pushed on the stack and the code
>>>> is jumped to without using any registers.
>>>>
>>>> As outlined in version 1, the kernel can push the data address on the stack
>>>> and write the code address into the PC and return to userland.
>>>>
>>>> For doing all of this, we need trampfd.
>>>
>>> We don't need this for FFI_REGISTER. I presented a solution that works
>>> in userspace. Even if you want to use a trampoline created by the
>>> kernel, there's no reason it needs to trap into the kernel at trampoline
>>> execution time. libffi's trampolines already handle this case today.
>>>
>>
>> libffi handles this using user level dynamic code which needs to be executed.
>> If the security subsystem prevents that, then the dynamic code cannot execute.
>> That is the whole point of this RFC.
>
> /If/ you are using a trampoline created by the kernel, it can just
> create the one that libffi is using today; which doesn't need trapping
> into the kernel at execution time.
>
> And if you aren't, you can use the trampoline I wrote, which has no
> dynamic code, and doesn't need to trap into the kernel at execution time
> either.
>
The kernel based solution gives you the opportunity to make additional
security checks at the time a trampoline is invoked. A purely user level
solution cannot do that. E.g., I would like to prevent even the minimal
trampoline from being used in BOP/ROP chains.
>>
>>>>
>>>> Permitting the use of trampfd
>>>> -----------------------------
>>>>
>>>> An "exectramp" setting can be implemented in SELinux to selectively allow the
>>>> use of trampfd for applications.
>>>>
>>>> Madhavan
>>>
>>> Applications can use their own userspace trampolines regardless of this
>>> setting, so it doesn't provide any additional security benefit by
>>> preventing usage of trampfd.
>>>
>>
>> The background for all of this is that dynamic code such as trampolines
>> need to be placed in a page with executable permissions so they can
>> execute. If security measures such as W^X are present, this will not
>> be possible. Admitted, today some user level tricks exist to get around
>> W^X. I have alluded to those. IMO, they are all security holes and will
>> get plugged sooner or later. Then, these trampolines cannot execute.
>> Currently, there exist security exceptions such as execmem to let them
>> execute. But we would like to do it without making security exceptions.
>>
>> Madhavan
>
> How can you still say this after this whole discussion? Applications can
> get the exact same functionality as your proposed trampfd using static
> code, no W^X tricks needed.
>
> This only matters if you have a trampfd that generates _truly_ dynamic
> code, not just code that can be trivially made static.
>
How can *you* still say this after all this discussion?
I have already explained all of this. The trivial bootstrap trampoline can
be provided in a user library as well the kernel. The user land solution
provides a fast trampoline that does the job. The kernel solution
is slower but allows for additional security checks that a user land
solution does not allow. IMO, it should be a choice what type of trampoline
the user wants.
And this is not just for libffi that we can somehow do this within libffi.
I would like to provide something so that the maintainers of other
dynamic code can use it to convert their dynamic code to static code
when their dynamic code is a lot more complex that the libffi trampoline.
I am already willing to implement a user land only solution. I don't see
the problem.
Madhavan
Before I implement the user land solution recommended by reviewers, I just want
an opinion on where the code should reside.
I am thinking glibc. The other choice would be a separate library, say, libtramp.
What do you recommend?
Madhavan