[RFC WIP] Apple whole dylib trampoline#621
Open
jeremyhu wants to merge 1 commit intolibffi:masterfrom
Open
Conversation
jeremyhu
force-pushed
the
apple-whole-dylib-trampoline
branch
from
fedfc7e to
d03a732
Compare
nsz-arm
reviewed
Jan 20, 2021
| /* Helpers for writing assembly compatible with arm ptr auth */ | ||
| #ifdef LIBFFI_ASM | ||
|
|
||
| #ifdef HAVE_PTRAUTH |
There was a problem hiding this comment.
this seems to be for generic code not just for apple which this is wrong:
- return address signing requires cfi annotation (toggle pac state)
- b key requires cfi annotation
- libffi should use nop-space instructions. armv8.3-a only asm can be added conditionally, but that's not relevant to most users: no linux distro would deploy binaries with armv8.3-a baseline any time soon.
- pauth and bti should go together in gcc target libraries: branch-protection requires both return address and indirect jump/call protection. at least that's the intended usage model. however bti support requires significant changes in the jump table as bti j does not fit there.
so if apple requires this then it should be apple only or changed such that it works for other targets too (at least aarch64*-linux-gnu), libitm aarch64/sjlj.S is an example how this was done in other target libraries.
Contributor
Author
sbogolepov
added a commit
to JetBrains/kotlin
that referenced
this pull request
Mar 17, 2021
Currently, upstream libffi doesn't support Apple Silicon. However, there are several PRs from Apple employees: * libffi/libffi#565 * libffi/libffi#621 Homebrew formulae for libffi contains patch that is based on these pull requests. We use this patch here to build our own version of libffi.
11 tasks
Contributor
|
Will libffi have a |
|
See #633. Wouldn't it be cleaner to just use libffi itself as the trampoline dylib? That'll work on every platform too. |
jeremyhu
force-pushed
the
apple-whole-dylib-trampoline
branch
from
d03a732 to
8b612c3
Compare
It is no longer allowed to simply vm_remap code pages willy-nilly. Only entire signed executable segment of a dylib may be remapped. Accordingly, we need a helper dylib (called libffi-trampolines.dylib) to support our use of vm_remap for trampolines. Signed-off-by: Jeremy Huddleston Sequoia <[email protected]>
jeremyhu
force-pushed
the
apple-whole-dylib-trampoline
branch
from
8b612c3 to
4b7be51
Compare
Contributor
|
Any news about upstreaming Apple Silicon support please? |
Contributor
Author
|
Sorry, no. I haven't had much time to circle back to this. Most of the work is here on this branch... mainly just need to get the build system changes in place to build the trampoline dylib. If you have time to help with that, it'd be great. The Xcode project can serve as reference. |
|
I would like to try getting this across the finish line. However, this is a little outside my comfort zone, and so I would like some help in creating a consistent failing reproducer that I can use to gauge how I am doing. /cc @jeremyhu |
|
@tjni 🎉 |
13 tasks
oleavr
reviewed
Aug 25, 2022
| * trampoline page | ||
| */ | ||
| kt = vm_allocate (mach_task_self (), &config_page, FFI_TRAMPOLINE_ALLOCATION_PAGE_COUNT * PAGE_MAX_SIZE, | ||
| VM_FLAGS_ANYWHERE); |
Contributor
There was a problem hiding this comment.
Note that ffi_trampoline_table_free() needs to be updated to avoid leaking memory, as it deallocates PAGE_MAX_SIZE * 2.
Contributor
|
Is there any news about this? |
oleavr
added a commit
to frida/libffi
that referenced
this pull request
Nov 1, 2022
Based on libffi#621 by @jeremyhu. So we can support iOS 15 and beyond. Co-authored-by: Jeremy Huddleston Sequoia <[email protected]> Co-authored-by: Håvard Sørbø <[email protected]>
oleavr
added a commit
to frida/libffi
that referenced
this pull request
Nov 1, 2022
So we can support iOS 15 and beyond. Based on libffi#621 by @jeremyhu. Co-authored-by: Jeremy Huddleston Sequoia <[email protected]> Co-authored-by: Håvard Sørbø <[email protected]>
oleavr
added a commit
to frida/libffi
that referenced
this pull request
Nov 1, 2022
So we can support iOS 15 and beyond. Based on libffi#621 by @jeremyhu. Co-authored-by: Jeremy Huddleston Sequoia <[email protected]> Co-authored-by: Håvard Sørbø <[email protected]>
oleavr
added a commit
to frida/libffi
that referenced
this pull request
Nov 1, 2022
So we can support iOS 15 and beyond. Based on libffi#621 by @jeremyhu. Co-authored-by: Jeremy Huddleston Sequoia <[email protected]> Co-authored-by: Håvard Sørbø <[email protected]>
oleavr
added a commit
to frida/libffi
that referenced
this pull request
Nov 8, 2022
So we can support iOS 15 and beyond. Based on libffi#621 by @jeremyhu. Co-authored-by: Jeremy Huddleston Sequoia <[email protected]> Co-authored-by: Håvard Sørbø <[email protected]>
oleavr
added a commit
to frida/libffi
that referenced
this pull request
Nov 9, 2022
So we can support iOS 15 and beyond. Based on libffi#621 by @jeremyhu. Co-authored-by: Jeremy Huddleston Sequoia <[email protected]> Co-authored-by: Håvard Sørbø <[email protected]>
oleavr
added a commit
to frida/libffi
that referenced
this pull request
Nov 9, 2022
So we can support iOS 15 and beyond. Based on libffi#621 by @jeremyhu. Co-authored-by: Jeremy Huddleston Sequoia <[email protected]> Co-authored-by: Håvard Sørbø <[email protected]>
github-actions bot
pushed a commit
to NixOS/nixpkgs
that referenced
this pull request
Nov 28, 2022
Trusts the libffi library inside of nixpkgs on Apple devices. When Apple's fork of libffi is not detected, cffi assumes that libffi uses a strategy for creating closures (i.e. callbacks) that is in certain cases susceptible to a security exploit. Based on some analysis I did: https://groups.google.com/g/python-cffi/c/xU0Usa8dvhk I believe that libffi already contains the code from Apple's fork that is deemed safe to trust in cffi. It uses a more sophisticated strategy for creating trampolines to support closures that works on Apple Silicon, while the simple approach that cffi falls back on does not, so this patch enables code that uses closures on M1 Macs again. Notably, pyOpenSSL is impacted and will be fixed by this, reported in pyca/pyopenssl#873 Note that libffi closures still will not work on signed apps without the com.apple.security.cs.allow-unsigned-executable-memory entitlement while libffi/libffi#621 is still open (which I haven't tested but is my best guess from reading). I am hopeful that all of these changes will be upstreamed back into cffi and libffi, and that this comment provides enough breadcrumbs for future maintainers to track and clean this up. (cherry picked from commit 4fc97dc)
jsoo1
pushed a commit
to awakesecurity/nixpkgs
that referenced
this pull request
Nov 30, 2023
Trusts the libffi library inside of nixpkgs on Apple devices. When Apple's fork of libffi is not detected, cffi assumes that libffi uses a strategy for creating closures (i.e. callbacks) that is in certain cases susceptible to a security exploit. Based on some analysis I did: https://groups.google.com/g/python-cffi/c/xU0Usa8dvhk I believe that libffi already contains the code from Apple's fork that is deemed safe to trust in cffi. It uses a more sophisticated strategy for creating trampolines to support closures that works on Apple Silicon, while the simple approach that cffi falls back on does not, so this patch enables code that uses closures on M1 Macs again. Notably, pyOpenSSL is impacted and will be fixed by this, reported in pyca/pyopenssl#873 Note that libffi closures still will not work on signed apps without the com.apple.security.cs.allow-unsigned-executable-memory entitlement while libffi/libffi#621 is still open (which I haven't tested but is my best guess from reading). I am hopeful that all of these changes will be upstreamed back into cffi and libffi, and that this comment provides enough breadcrumbs for future maintainers to track and clean this up.
jsoo1
pushed a commit
to awakesecurity/nixpkgs
that referenced
this pull request
Dec 7, 2023
Trusts the libffi library inside of nixpkgs on Apple devices. When Apple's fork of libffi is not detected, cffi assumes that libffi uses a strategy for creating closures (i.e. callbacks) that is in certain cases susceptible to a security exploit. Based on some analysis I did: https://groups.google.com/g/python-cffi/c/xU0Usa8dvhk I believe that libffi already contains the code from Apple's fork that is deemed safe to trust in cffi. It uses a more sophisticated strategy for creating trampolines to support closures that works on Apple Silicon, while the simple approach that cffi falls back on does not, so this patch enables code that uses closures on M1 Macs again. Notably, pyOpenSSL is impacted and will be fixed by this, reported in pyca/pyopenssl#873 Note that libffi closures still will not work on signed apps without the com.apple.security.cs.allow-unsigned-executable-memory entitlement while libffi/libffi#621 is still open (which I haven't tested but is my best guess from reading). I am hopeful that all of these changes will be upstreamed back into cffi and libffi, and that this comment provides enough breadcrumbs for future maintainers to track and clean this up.
jsoo1
pushed a commit
to awakesecurity/nixpkgs
that referenced
this pull request
Dec 14, 2023
Trusts the libffi library inside of nixpkgs on Apple devices. When Apple's fork of libffi is not detected, cffi assumes that libffi uses a strategy for creating closures (i.e. callbacks) that is in certain cases susceptible to a security exploit. Based on some analysis I did: https://groups.google.com/g/python-cffi/c/xU0Usa8dvhk I believe that libffi already contains the code from Apple's fork that is deemed safe to trust in cffi. It uses a more sophisticated strategy for creating trampolines to support closures that works on Apple Silicon, while the simple approach that cffi falls back on does not, so this patch enables code that uses closures on M1 Macs again. Notably, pyOpenSSL is impacted and will be fixed by this, reported in pyca/pyopenssl#873 Note that libffi closures still will not work on signed apps without the com.apple.security.cs.allow-unsigned-executable-memory entitlement while libffi/libffi#621 is still open (which I haven't tested but is my best guess from reading). I am hopeful that all of these changes will be upstreamed back into cffi and libffi, and that this comment provides enough breadcrumbs for future maintainers to track and clean this up.
jsoo1
pushed a commit
to awakesecurity/nixpkgs
that referenced
this pull request
Dec 22, 2023
Trusts the libffi library inside of nixpkgs on Apple devices. When Apple's fork of libffi is not detected, cffi assumes that libffi uses a strategy for creating closures (i.e. callbacks) that is in certain cases susceptible to a security exploit. Based on some analysis I did: https://groups.google.com/g/python-cffi/c/xU0Usa8dvhk I believe that libffi already contains the code from Apple's fork that is deemed safe to trust in cffi. It uses a more sophisticated strategy for creating trampolines to support closures that works on Apple Silicon, while the simple approach that cffi falls back on does not, so this patch enables code that uses closures on M1 Macs again. Notably, pyOpenSSL is impacted and will be fixed by this, reported in pyca/pyopenssl#873 Note that libffi closures still will not work on signed apps without the com.apple.security.cs.allow-unsigned-executable-memory entitlement while libffi/libffi#621 is still open (which I haven't tested but is my best guess from reading). I am hopeful that all of these changes will be upstreamed back into cffi and libffi, and that this comment provides enough breadcrumbs for future maintainers to track and clean this up.
jsoo1
pushed a commit
to awakesecurity/nixpkgs
that referenced
this pull request
Jan 13, 2024
Trusts the libffi library inside of nixpkgs on Apple devices. When Apple's fork of libffi is not detected, cffi assumes that libffi uses a strategy for creating closures (i.e. callbacks) that is in certain cases susceptible to a security exploit. Based on some analysis I did: https://groups.google.com/g/python-cffi/c/xU0Usa8dvhk I believe that libffi already contains the code from Apple's fork that is deemed safe to trust in cffi. It uses a more sophisticated strategy for creating trampolines to support closures that works on Apple Silicon, while the simple approach that cffi falls back on does not, so this patch enables code that uses closures on M1 Macs again. Notably, pyOpenSSL is impacted and will be fixed by this, reported in pyca/pyopenssl#873 Note that libffi closures still will not work on signed apps without the com.apple.security.cs.allow-unsigned-executable-memory entitlement while libffi/libffi#621 is still open (which I haven't tested but is my best guess from reading). I am hopeful that all of these changes will be upstreamed back into cffi and libffi, and that this comment provides enough breadcrumbs for future maintainers to track and clean this up.
tm-drtina
pushed a commit
to awakesecurity/nixpkgs
that referenced
this pull request
Feb 27, 2024
Trusts the libffi library inside of nixpkgs on Apple devices. When Apple's fork of libffi is not detected, cffi assumes that libffi uses a strategy for creating closures (i.e. callbacks) that is in certain cases susceptible to a security exploit. Based on some analysis I did: https://groups.google.com/g/python-cffi/c/xU0Usa8dvhk I believe that libffi already contains the code from Apple's fork that is deemed safe to trust in cffi. It uses a more sophisticated strategy for creating trampolines to support closures that works on Apple Silicon, while the simple approach that cffi falls back on does not, so this patch enables code that uses closures on M1 Macs again. Notably, pyOpenSSL is impacted and will be fixed by this, reported in pyca/pyopenssl#873 Note that libffi closures still will not work on signed apps without the com.apple.security.cs.allow-unsigned-executable-memory entitlement while libffi/libffi#621 is still open (which I haven't tested but is my best guess from reading). I am hopeful that all of these changes will be upstreamed back into cffi and libffi, and that this comment provides enough breadcrumbs for future maintainers to track and clean this up.
cooljeanius
approved these changes
Nov 1, 2024
reckenrode
added a commit
to NixOS/nixpkgs
that referenced
this pull request
Feb 17, 2025
sandptel
pushed a commit
to sandptel/nixpkgs
that referenced
this pull request
Mar 13, 2025
5 tasks
1 task
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
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.
This pull request follows up upon #565 to finish providing support for Apple Silicon. These changes are from Apple's libffi-27 (with some additional cleanup).
TODO:
1. Don't hard code the path to the trampoline dylib
2. Build the trampoline dylib