Skip to content

Conversation

@jrick
Copy link
Member

@jrick jrick commented Jul 26, 2021

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.

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.
@jrick
Copy link
Member Author

jrick commented Jul 26, 2021

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 /lib/ld-musl-x86_64.so.1. Trying to execute the PIE built by this PR results in a not-immediately-obvious error message ./dcrwallet: not found.

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).

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.

1 participant