-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UPX compressed arm64/amd64/x86_64 executable crashes on macOS Ventura 13.0 #612
Comments
I fear we do not have enough info to support macOS 13 at this time - has Apple released any current kernel/libc/ld/... source code yet? |
Info from #613 : macOS 13 source code has been released https://github.com/apple-oss-distributions/xnu |
Unsurprislingly arm64 macos13 also doesn't work. |
@markus-oberhumer The comment |
|
@chchwy On Apple M1 hardware, then MacOS 13.0 (Ventura) with Xcode 14.1 (Nov.1, 2022) is not ready for prime time:
Suggestions? |
@markus-oberhumer Your report omitted the observed behavior, so is not reproducible. Digging deeply, I see
So probably the error is ENOEXEC or EBADEXEC. What you see? |
Run the following command before cmake. Please specify the Xcode.app path to the one you installed.
Probably you also need to open the Xcode app for the license accepting stuff for the first time. |
We're seeing the same behavior on Google Closure Compiler: google/closure-compiler-npm#265 Oddly enough, an amd64 binary run on a M1 Mac via Rosetta does not exhibit the issue. Only when the binary is run on a non-M1 Mac does this come up. |
UPX-compressed binaries are not working on macOS 13[1]. [1]: upx/upx#612
Bug in upx that is as yet unresolved (upx/upx#612).
Bug in upx that is as yet unresolved (upx/upx#612).
@chenrui333 Sounds reasonable. Hopefully we will be able to support macOS 13+ at some future point... |
Packing macOS binaries is disabled in |
the segmentation fault is due to upx compression of the binary issue with upx mentioned in upx/upx#612
For what it's worth, I did some poking around (unrelated to y'all's project) - I have found references to something called Presently all the syscalls for Exclaves are stubbed out to simply return Whatever Exclaves are, they're internal to Apple, at least for now. I'm not sure if they're active on current versions of *OS or not. Luckily, they can be disabled. To do so, you need to remove
Now everything should behave as normal (however due to other, unrelated, errors I haven't managed to actually build the kernel yet - but |
Could you please provide exact instructions how you are building the xnu kernel? I'm stuck at My setup on a Mac Mini M2, Darwin 22.6.0:
|
Ah my b - I forgot about something else I had to add to my make invocation. Here's the full command I'm running: make SDKROOT=macosx ARCH_CONFIGS="X86_64 ARM64" KERNEL_CONFIGS=RELEASE TIGHTBEAMC==nothx LOGCOLORS=y RC_DARWIN_KERNEL_VERSION=23.0.0 I borked my macOS SDK when I ran the same invocation with the addition of the I stopped there and haven't had time to try continuing onwards. The guide I'm following is a mish mash of the *OS internals book's instructions and the ones found at https://kernelshaman.blogspot.com/2021/02/building-xnu-for-macos-112-intel-apple.html I had to make some adjustments, attached below are the notes I took about what has changed about the process. Best of luck, and if you figure out how to compile it, please do share! Regardless, I'll be back when I figure out how to compile it. Compiling XNU for Apple Silicon
Install DependenciesDTrace/ctf*
AvailabilityVersions
Install XNU Headers
|
Many thanks for your info! I'm thinking about creating a GitHub Actions workflow that clones the But then I'm sure somebody else must have had this idea. Any hints? |
I've created https://github.com/upx/upx-fork-apple-oss-distributions-xnu , please continue XNU build discussions there. |
I've never used GitHub Actions before - so unfortunately I can't help you there. I'll add updates to the XNU fork as I figure things out though. |
@tomnific Well, GitHub Actions are basically shell scripts that are run in a container (more technically its a YAML file that is parsed by NodeJS which then generates and runs the shell scripts). Please visit upx/upx-fork-apple-oss-distributions-xnu#1 |
- relates to [upx/upx#612](upx/upx#612) Co-Authored-By: Rui Chen <rui@chenrui.dev> upx (test): add `--force-macos` - See Homebrew#160367
I guess I wrote a script to verify this
This script add MH_DYLDLINK and LC_LOAD_DYLINKER to the executable, the
lldb
|
@61bcdefg Thank you for the URLs and script! That is progress in understanding the requirements of MacOS. At first glance, it looks like the site of the SIGSEGV, namely UPX would rather not construct a compressed executable with all that baggage: it occupies space and could easily interfere with the de-compressed program. What if the dylinker used by UPX is not the same as the one used by the de-compressed program, what if the system library does not understand being "initialized" twice (once by the UPX de-compresion stub, once by the de-compressed program), etc. Because of the current murkiness involving instantiation and initialization that is performed by |
Is there a good alternative until this is fixed? |
There is no alternative known to us. The Apple documentation known to us is not specific enough to implement against (what are the exact requirements for |
Well, if the only thing that matters is small download size: compress the executable using your favorite file compressor, and make a shell archive (such as |
Have you ever try https://github.com/blacktop/darwin-xnu-build |
This issue tracker is ONLY used for reporting bugs.
Please use stackoverflow for supporting issues.
What's the problem (or question)?
The UPX compressed amd64 executable crashes on macOS 13.0.
I made a small CMake project which merely print out a few lines of text for reproducing the crash.
Here are the commands I used to compress the executable. Then it crashed immediately after I ran the compressed one.
lldb
What should have happened?
It should print the same text as before it was compressed.
This is the output when it is not compressed.
Do you have an idea for a solution?
Actually no, but It was working on macOS 12.
How can we reproduce the issue?
I made a tiny CMake project with 16 lines of code for this bug report. It is configured to generate an amd64 executable. (Not arm64)
mkdir build
cd build
cmake .. -G Xcode
cmake --build .
upx -vk ./Debug/HelloUPX4 -o./Debug/HelloUPX4-compressed
./Debug/HelloUPX4-compressed
<= crashed herePlease tell us details about your environment.
upx --version
): 3.96 (I tried the latest devel4 branch and it doesn't work either)The text was updated successfully, but these errors were encountered: