Skip to content
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

fix: prevent dynamic linking when targeting musl #109

Merged
merged 1 commit into from
Apr 4, 2023

Conversation

Orycterope
Copy link
Contributor

When targeting x86_64-unknown-linux-musl, the default features will successfully compile a binary that always segfaults when run (see #106). This is because the default features will try to dynamic link against libyara.so, which means adding it to the list of dynamic dependencies in the resulting ELF for it to be loaded by the ld (glibc) interpreter at the start of the program execution.

However, musl binaries produced by rustc do not have any interpreter, they jump straight to the ELF's entrypoint, and libyara.so is never loaded, even though it is listed as a dynamic dependencies in the ELF. This of course ultimately results in a segfault when trying to access any memory belonging to libyara.so, since it was not loaded in our address space.

In my opinion this is a bug in rustc, it should never allow dynamic linking when targeting musl, and this has been reported in this issue rust-lang/rust#82193

Until it is fixed in rustc, this PR adds a new check in build.rs to abort compilation when dynamic linking and targeting musl, and prompts the user to use the yara-static feature instead to static link against libyara.a instead of libyara.so, because that's probably what they actually want when targeting musl.

@Orycterope Orycterope changed the title fix: prevent dynamic linking when targetting musl fix: prevent dynamic linking when targeting musl Mar 26, 2023
Copy link
Contributor

@ikrivosheev ikrivosheev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, LGTM!

@Hugal31 Hugal31 merged commit c621fe7 into Hugal31:master Apr 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants