Open
Conversation
PIE provides additional hardening by loading the program code at random offsets each execution, rather than all code being mapped to a static memory location. This complicates attacks such as ROP which require jumping to known gadgets in the program text. Other targets also support PIE, but it does not appear to be possible to link the executable in a cross compile situation without the platform's native linker. This is the case for linux/386, linux/arm, and freebsd/amd64. As a consequence of producing a PIE, the Linux executables will now link to the dynamic link editor (e.g. /lib64/ld-linux-x86-64.so.2 for amd64), and will no longer run on distributions which do not provide the link editor the expected path. This is not expected to be a common issue for most distributions, and for those that are affected because of their reproducibility guarantees (e.g. NixOS), tooling is available to patch the path to the dynamic link editor in the ELF file.
Member
Author
|
Seems like I overlooked the possibility of musl-based distributions, which do not keep their ld.so at the same path as what Go will use by default (for glibc). On the latest Alpine release, the amd64 dynamic loader is If the ldflags are modified to use -I to change the path to the dynamic linker, we could create musl versions of these executables alongside the glibc ones as well (I've tested this, and it works), but I'm not sure if this is the best idea, especially since some of the 32-bit linux executables won't be specific to any particular libc (they are true static executables). |
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
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.
PIE provides additional hardening by loading the program code at
random offsets each execution, rather than all code being mapped to a
static memory location. This complicates attacks such as ROP which
require jumping to known gadgets in the program text.
Other targets also support PIE, but it does not appear to be possible
to link the executable in a cross compile situation without the
platform's native linker. This is the case for linux/386, linux/arm,
and freebsd/amd64.
As a consequence of producing a PIE, the Linux executables will now
link to the dynamic link editor (e.g. /lib64/ld-linux-x86-64.so.2 for
amd64), and will no longer run on distributions which do not provide
the link editor the expected path. This is not expected to be a
common issue for most distributions, and for those that are affected
because of their reproducibility guarantees (e.g. NixOS), tooling is
available to patch the path to the dynamic link editor in the ELF
file.