| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
overwriting NOBITS entries.
|
| |
|
|\
| |
| | |
Allow multiple filenames to patch
|
| |
| |
| |
| |
| |
| |
| | |
This makes behaviour less confusing when multiple filenames are
passed — previously, any extra filenames would be ignored completely,
as would any options passed after a filename. Now these are taken
into account.
|
| | |
|
|\ \ |
|
| | | |
|
| |/
| |
| |
| | |
weak ordering as required by std::sort.
|
|\ \
| |/
|/| |
Better error messages when run on statically-linked (or otherwise weird) binaries
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, patchelf outputs this when run on a UPX-compressed ELF file:
patchelf: patchelf.cc:420: ElfFile<Elf_Ehdr, Elf_Phdr, Elf_Shdr, Elf_Addr, Elf_Off, Elf_Dyn, Elf_Sym, Elf_Verneed>::ElfFile(FileContents): Assertion `shstrtabIndex < shdrs.size()' failed.
Make it give a nicer error message:
patchelf: no section headers. The input file is probably a statically linked, self-decompressing binary
Fixes #63
|
| |
| |
| |
| |
| | |
If .dynamic, .dynstr or .interp sections aren't found, give an extra hint
to the user that the input file is statically linked.
|
| |
| |
| |
| | |
Reported by Jannis Harder.
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current approach to changing sections in ET_DYN executables is to move
the INTERP section to the end of the file. +This means changing PT_PHDR to
add an extra PT_LOAD section so that the new section is mmaped into memory
by the elf loader in the kernel. In order to extend PHDR, this means moving
it to the end of the file.
Its documented in BUGS there is a kernel 'bug' which means that if you have holes
in memory between the base load address and the PT_LOAD segment that contains PHDR,
it will pass an incorrect PHDR address to ld.so and fail to load the binary, segfaulting.
To avoid this, the code currently inserts space into the binary to ensure that when
loaded into memory there are no holes between the PT_LOAD sections. This inflates the
binaries by many MBs in some cases. Whilst we could make them sparse, there is a second
issue which is that strip can fail to process these binaries:
$ strip fixincl
Not enough room for program headers, try linking with -N
[.note.ABI-tag]: Bad value
This turns out to be due to libbfd not liking the relocated PHDR section either
(https://github.com/NixOS/patchelf/issues/10).
Instead this patch implements a different approach, leaving PHDR where it is but extending
it in place to allow addition of a new PT_LOAD section. This overwrites sections in the
binary but those get moved to the end of the file in the new PT_LOAD section.
This is based on patches linked from the above github issue, however whilst the idea
was good, the implementation wasn't correct and they've been rewritten here.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|/
|
|
| |
http://hydra.nixos.org/build/49825195
|
|
|
|
|
|
|
| |
We don't really care whether DT_STRTAB is correct, since we overwrite
it anyway.
https://github.com/NixOS/nixpkgs/issues/22333
|
| |
|
|
|
|
| |
Fixes #93.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #97. In essence, the problem is that some packages in Nixpkgs have
RPATHs pointing to both $NIX_BUILD_TOP and $out, e.g.:
/tmp/nix-build-openldap-2.4.44.drv-0/openldap-2.4.44/libraries/libldap_r/.libs
/tmp/nix-build-openldap-2.4.44.drv-0/openldap-2.4.44/libraries/liblber/.libs
/nix/store/bfkmdxmv3a3f0g3d2q8jkdz2wam93c5z-openldap-2.4.44/lib
/nix/store/bfkmdxmv3a3f0g3d2q8jkdz2wam93c5z-openldap-2.4.44/lib64
Currently, running `patchelf --shrink-rpath` does the wrong thing by
keeping the /tmp/ paths and deleting the /nix/store ones. Now we can fix
the problem by using
patchelf --shrink-rpath --allowed-rpath-prefixes $NIX_STORE_DIR
in the Nixpkgs fixupPhase instead.
|
|
|
|
|
| |
We're going to need this logic in another place, so make a function of
this.
|
| |
|
|
|
|
| |
Issue #66
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When writing the code to teach --replace-needed to modify the
.gnu.version_r section (gh-85), I misunderstood how the ->vn_next
pointers in the Elf_Verneed structs are supposed to be interpreted: I
thought they gave an offset from the beginning of the section, but in
fact they give an offset relative to the current struct. The resulting
bug was very odd: generally, patchelf would complete without signalling
an error, but it would only successfully replace filenames that occurred
as either the first or second entries in the .gnu.version_r section,
while the third or later entries would be left untouched.
This commit fixes the interpretation of the ->vn_next pointers, so that
now --replace-needed should work correctly even on ELF files with more
than two version needed structs.
Thanks to @matthew-brett for finding the bug / providing a test case,
and to @rmcgibbo for helping me diagnose it.
|
|
|
|
|
|
| |
No semantic changes, but I noticed some small errors in the DT_NEEDED
handling loop while I was adding the .gnu.version_r handling, so might
as well fix them while I'm here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the ELF binary that we're patching is linked to a DSO that uses
symbol versioning, then the DSO's SONAME appears in two different
places: once as a DT_NEEDED entry, and once in the .gnu.version_r
version requirements section. Previously, patchelf --replace-needed
would update DT_NEEDED entry, but fail to update the .gnu.version_r
table. This resulted in completely broken binaries -- trying to load
them would trigger an assertion failure inside the dynamic loader, as it
tries to check the version of a library that was never loaded:
Inconsistency detected by ld.so: dl-version.c: 224: _dl_check_map_versions: Assertion `needed != ((void *)0)' failed!
This commit teaches --replace-needed to update the .gnu.version_r
table.
Fixes: gh-84
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because this assumption doesn't seem to be valid either in theory or
practice: the spec (http://refspecs.linuxbase.org/elf/elf.pdf) only
places these requirements on PT_PHDR:
"This segment type may not occur more than once in a file. Moreover,
it may occur only if the program header table is part of the memory
image of the program. If it is present, it must precede any loadable
segment entry."
And on ARM, binaries generated by GNU GCC / binutils almost never have
PT_PHDR as the first entry, e.g. the coreutils 'ls' has this:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x0169b4 0x0001e9b4 0x0001e9b4 0x00008 0x00008 R 0x4
PHDR 0x000034 0x00008034 0x00008034 0x00120 0x00120 R E 0x4
INTERP 0x000154 0x00008154 0x00008154 0x0004f 0x0004f R 0x1
[Requesting program interpreter: /nix/store/whcad4dnkp5pnhbv4p0f9k8srv0kmcjk-glibc-2.21/lib/ld-linux-armhf.so.3]
LOAD 0x000000 0x00008000 0x00008000 0x169c0 0x169c0 R E 0x8000
LOAD 0x0169c0 0x000269c0 0x000269c0 0x003f4 0x01088 RW 0x8000
DYNAMIC 0x0169cc 0x000269cc 0x000269cc 0x000f8 0x000f8 RW 0x4
NOTE 0x0001a4 0x000081a4 0x000081a4 0x00020 0x00020 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
PAX_FLAGS 0x000000 0x00000000 0x00000000 0x00000 0x00000 0x4
This problem has existed for quite a long time on ARM and often results
in patchelf'd programs segfaulting inside the glibc dynamic linker,
which relies on PT_PHDR containing valid contents. This has been worked
around in Nixpkgs in various creative ways, like:
https://github.com/NixOS/nixpkgs/blob/5c20877d40726b6973d222f71fa6e306428c19cf/nixos/modules/system/boot/stage-1.nix#L109
Applying patchelf twice did actually work in practice due to the fact
that patchelf sorts the program headers, causing the first round
of patchelf to rewrite an invalid PT_PHDR to appear first, and then
the second round of patchelf fixing that PT_PHDR.
|
|\ |
|
| | |
|
| | |
|
|/
|
|
| |
Because why not?
|
|
|
|
|
|
|
|
|
|
| |
This mostly reverts 08050dd5e3701b29e5628e1ec7d37c1cd6529c57 (#54)
because the page size of the host is not necessarily the same as the
page size of the binary. For a proper fix, we'll need some way to
determine the page size of the binary, but ELF doesn't readily provide
this information.
Fixes #69.
|
|\ |
|
| | |
|
|\ \ |
|
| |/
| |
| | |
`--set-soname` now creates a new DT_SONAME entry if it doesn't exist.
|
|\ \ |
|
| |/
| |
| |
| | |
I forgot to do that with this commit: https://github.com/NixOS/patchelf/commit/8eb28c00b6a78928cfa91728b1eba911a4ef49c1
Warnings only appear if -Wextra is turned on.
|
|/
|
| |
Get rid of remaining sing-compare warnings that appear when using gcc 5.2.
|
|\ |
|
| |
| |
| |
| |
| | |
Some DT_REL files are missing both .rel.dyn and .rel.got. This doesn't
seem to be an error, so it shouldn't be treated as such.
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| | |
When rewriting the sections of an executable, it can happen that the
section headers occur too early in the file and would be overwritten by
the replaced sections. If this would happen, we move the section headers
to the end of the file.
|
|\ \ |
|
| | | |
|