Allocate PHT & SHT at the end of the *.elf file

[Patryk27]

Closes #531.
Closes #482.
Closes #244.

Upstream-wise, affects NixOS/nixpkgs#226339.
(didn't want to write close so that merging this merge request doesn't close that issue at once)

Abstract

Patching an *.elf file might require extending its program header table, which can then cause it to run out of its originally allocated space (both in terms of file offset and virtual memory).

Currently patchelf solves this problem by finding which sections would overlap PHT and then by moving them to the end of *.elf file:

patchelf/src/patchelf.cc

Line 832 in 7c2f768

while( i < rdi(hdr()->e_shnum) && rdi(shdrs.at(i).sh_offset) <= pht_size ) {

As compared to similar logic for binaries:

patchelf/src/patchelf.cc

Line 964 in 7c2f768

if ((rdi(shdr.sh_type) == SHT_PROGBITS && sectionName != ".interp")

... the logic for libraries is missing a crucial check: it doesn't take into account whether that particular section can be shuffled around - in particular, sections with SHT_PROGBITS can't!

As luck would have it, libnode.so (e.g. shipped together with pcloud) does have .rodata (a section with SHT_PROGBITS active) right at the beginning of the file:

; readelf -S libnode.so

There are 29 section headers, starting at offset 0x152bf70:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .rodata           PROGBITS         0000000000000240  00000240
       00000000003796a8  0000000000000000 AMS       0     0     32
/* ... */

... which patchelf happily moves around, breaking RIP-relative addressing in the assembly (which, after patching, tries to access the ZZZZ-ed memory).

This commit fixes the issue by changing the logic from:

if there's no space for PHT, shuffle sections around

... to, perhaps a bit more wasteful in terms of storage:

just always allocate PHT at the end of the file

As far as I've checked, the reason why PHT was so strictly kept at the beginning was an old Linux bug:

patchelf/src/patchelf.cc

Line 857 in 7c2f768

/* Even though this file is of type ET_DYN, it could actually be

patchelf/BUGS

Line 1 in 7c2f768

Bug in Linux kernel, in fs/binfmt_elf.c:

... which is not present anymore (not sure when precisely was it fixed, though - the original entry in the BUGS file is dated 2005).

Seizing the day, I'm also including another fix (for binaries), so that merging this pull request will solve all pcloud-related problems.

[Patryk27]

Previously PHDR was always kept right after EHDR, while now it's allocated at the end of the file.

[Patryk27]

That's because now we might sometimes allocate a brand-new LOAD segment just for the PHDR's sake.

[Patryk27]

This logic used to be run only if neededSpace <= startOffset, under the assumption that otherwise (when neededSpace > startOffset), we call shiftFile(), which will automatically create appropriate PT_LOAD segment:

patchelf/src/patchelf.cc

Line 557 in 7c2f768

/* Add a segment that maps the new program/section headers and

But that was done under the assumption that shiftFile()'s startOffset will land inside a loadable segment that happens to contain PHDR, which is not necessarily true! Some binaries have a dedicated small LOAD segment just for PHDR, making shiftFile() then pick the next available LOAD segment.

I believe this is the same case this merge request tried to cover (or at least both make pcloud a valid binary):

#264

I've also checked it on the reproduction from #264 (comment) - I don't have aarch64-linux at hand, though, so I've just patched the file and ran eu-elflint (which now doesn't complain about the string sections there).

Also, this is now tested as a part of short-first-segment.

[Patryk27]

Hmm, in a hindsight, now I'm thinking whether this approach can't cause some segments to overlap each other? (maybe that's why tests on a few other architectures fail, as I now see)

[Patryk27]

Btw, I've got another merge request in the works, one that fixes #75 and hopefully will be able to handle #520 as well, but I've ultimately decided to move it out of this pull request, since it's technically a separate changeset (and less important, at least from my point of view) -- I'll prepare it in the upcoming weeks.

[jvolkman]

Another issue is that strip doesn't like binaries with with the PHT and SHT bits at the end, and will either fail or generate invalid binaries as output. One workaround is to just strip first, but I guess this is not possible in all workflows.

See #117 and #10.

Definitely seems like a strip/libbfd bug since, as far as can tell, nothing in the ELF spec requires these tables to be at the top. I spent a couple days stepping through bfd/elf.c back when I was working on this (which also places the updated headers at the end), but I was ultimately unable to decipher what was going on.