Static trampolines version 1 #603
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closure Trampoline Security Issue
=================================
Currently, the trampoline code used in libffi is not statically defined in
a source file (except for MACH). The trampoline is either pre-defined
machine code in a data buffer. Or, it is generated at runtime. In order to
execute a trampoline, it needs to be placed in a page with executable
permissions.
Executable data pages are attack surfaces for attackers who may try to
inject their own code into the page and contrive to have it executed. The
security settings in a system may prevent various tricks used in user land
to write code into a page and to have it executed somehow. On such systems,
libffi trampolines would not be able to run.
Static Trampoline
=================
To solve this problem, the trampoline code needs to be defined statically
in a source file, compiled and placed in the text segment so it can be
mapped and executed naturally without any tricks. However, the trampoline
needs to be able to access the closure pointer at runtime.
PC-relative data referencing
============================
The solution implemented in this patch set uses PC-relative data references.
The trampoline is mapped in a code page. Adjacent to the code page, a data
page is mapped that contains the parameters of the trampoline:
- the closure pointer
- pointer to the ABI handler to jump to
The trampoline code uses an offset relative to its current PC to access its
data.
Some architectures support PC-relative data references in the ISA itself.
E.g., X64 supports RIP-relative references. For others, the PC has to
somehow be loaded into a general purpose register to do PC-relative data
referencing. To do this, we need to define a get_pc() kind of function and
call it to load the PC in a desired register.
There are two cases:
1. The call instruction pushes the return address on the stack.
In this case, get_pc() will extract the return address from the stack
and load it in the desired register and return.
2. The call instruction stores the return address in a designated register.
In this case, get_pc() will copy the return address to the desired
register and return.
Either way, the PC next to the call instruction is obtained.
Scratch register
================
In order to do its job, the trampoline code would be required to use a
scratch register. Depending on the ABI, there may not be a register
available for scratch. This problem needs to be solved so that all ABIs
will work.
The trampoline will save two values on the stack:
- the closure pointer
- the original value of the scratch register
This is what the stack will look like:
sp before trampoline ------> --------------------
| closure pointer |
--------------------
| scratch register |
sp after trampoline -------> --------------------
The ABI handler can do the following as needed by the ABI:
- the closure pointer can be loaded in a desired register
- the scratch register can be restored to its original value
- the stack pointer can be restored to its original value
(when the trampoline was invoked)
Thus the ABI handlers will have a couple of lines of code at the very
beginning to do this so that all ABIs will work.
NOTE:
The documentation for this feature will contain information on:
- the name of the scratch register for each architecture
- the stack offsets at which the closure and the scratch register
will be copied
Trampoline Table
================
In order to reduce the trampoline memory footprint, the trampoline code
would be defined as a code array in the text segment. This array would be
mapped into the address space of the caller. The mapping would, therefore,
contain a trampoline table.
Adjacent to the trampoline table, there will be a data mapping that contains
a parameter table, one parameter block for each trampoline. The parameter
table will contain:
- a pointer to the closure
- a pointer to the ABI handler
The trampoline code would finally look like this:
- Make space on the stack for the closure and the scratch register
by moving the stack pointer down
- Store the original value of the scratch register on the stack
- Using PC-relative reference, get the closure pointer
- Store the closure pointer on the stack
- Using PC-relative reference, get the ABI handler pointer
- Jump to the ABI handler
Trampoline API
==============
There is a lot of dynamic code out there. They all have the same security
issue. Dynamic code can be re-written into static code provided the data
required by the static code can be passed to it just like we pass the
closure pointer to an ABI handler.
So, the same trampoline functions used by libffi internally need to be
made available to the rest of the world in the form of an API. The
following API has been defined in this solution:
int ffi_tramp_is_supported(void);
To support static trampolines, code needs to be added to each
architecture. Also, the feature itself can be enabled via a
configuration option. So, this function tells us if the feature
is supported and enabled in the current libffi or not.
void *ffi_tramp_alloc (int flags);
Allocate a trampoline. Currently, flags are zero. An opaque
trampoline structure pointer is returned.
Internally, libffi manages trampoline tables and individual
trampolines in each table.
int ffi_tramp_set_parms (void *tramp, void *target, void *data);
Initialize the parameters of a trampoline. That is, the target code
that the trampoline should jump to and the data that needs to be
passed to the target code.
void *ffi_tramp_get_addr (void *tramp);
Return the address of the trampoline to invoke the trampoline with.
The trampoline can be invoked in one of two ways:
- Simply branch to the trampoline address
- Treat the trampoline address as a function pointer and
call it.
Which method is used depends on the target code.
void ffi_tramp_free (void *tramp);
Free a trampoline.
Configuration
=============
A new configuration option, --enable-static-tramp has been added to enable
the use of static trampolines.
Mapping size
============
The size of the code mapping that contains the trampoline table needs to be
determined on a per architecture basis. If a particular architecture
supports multiple base page sizes, then the largest base page size needs to
be chosen. E.g., we choose 16K for ARM64.
Trampoline allocation and free
==============================
Static trampolines are allocated in ffi_closure_alloc() and freed in
ffi_closure_free().
Normally, applications use these functions. But there are some cases out
there where the user of libffi allocates and manages its own closure
memory. In such cases, the static trampoline API cannot be used. These
will fall back to using legacy trampolines. The user has to make sure
that the memory is executable.
ffi_closure structure
=====================
I did not want to make any changes to the size of the closure structure for
this feature to guarantee compatibility. But the opaque static trampoline
handle needs to be stored in the closure. I have defined it as follows:
- char tramp[FFI_TRAMPOLINE_SIZE];
+ union {
+ char tramp[FFI_TRAMPOLINE_SIZE];
+ void *ftramp;
+ };
If static trampolines are used, then tramp[] is not needed to store a
dynamic trampoline. That space can be reused to store the handle. Hence,
the union.
Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
- Define the arch-specific initialization function ffi_tramp_arch () that returns trampoline size information to common code. - Define the trampoline code and data mapping sizes. - Introduce a tiny amount of code at the beginning of each ABI handler to retrieve the information saved by the trampoline on stack. - Define the trampoline code table statically. - Call ffi_closure_tramp_init () to initialize static trampoline parameters from ffi_prep_closure_loc (). Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
- Define the arch-specific initialization function ffi_tramp_arch () that returns trampoline size information to common code. - Define the trampoline code and data mapping sizes. - Introduce a tiny amount of code at the beginning of each ABI handler to retrieve the information saved by the trampoline on stack. - Define the trampoline code table statically. - Call ffi_closure_tramp_init () to initialize static trampoline parameters from ffi_prep_closure_loc (). Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
- Define the arch-specific initialization function ffi_tramp_arch () that returns trampoline size information to common code. - Define the trampoline code and data mapping sizes. - Introduce a tiny amount of code at the beginning of each ABI handler to retrieve the information saved by the trampoline on stack. - Define the trampoline code table statically. - Call ffi_closure_tramp_init () to initialize static trampoline parameters from ffi_prep_closure_loc (). Signed-off-by: Madhavan T. Venkataraman <madvenka@linux.microsoft.com>
atgreen
requested changes
Dec 2, 2020
|
Actually, tramp.c did have condition compilation. Unfortunately, the includes were outside of the #ifdef. I have fixed that problem and created a separate branch with that fix and other changes (static_tramp_v2). I am closing this PR. I have submitted a PR for the new branch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have submitted an RFC for this change to the libffi alias. I am submitting this PR to trigger CI testing.
Closure trampolines are defined as dynamic code today - that is, either hand-crafted and placed in a data buffer or runtime generated. The trampolines need to be mapped with executable permissions. Executable data pages can potentially be hacked by an attacker. To address this, we need to define the trampolines statically in a source file so they can be compiled, placed in a text segment and mapped using traditional methods. An example of this has already been implemented in MACH for the ARM architecture. However, we need to generalize the implementation for all architectures and also make sure that no ABI breaks on any architecture.
The Static Trampolines work is an attempt to achieve that. I have added support for X86 and ARM, 32-bit and 64-bit. Support for other architectures can be added easily in the future. For more information, please refer to the RFC I have submitted on the libffi alias.