[Bug binutils/31208] New: strip with no arguments sometimes breaks ELF alignment requirements

[godlygeek at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31208

Bug ID: 31208
   Summary: strip with no arguments sometimes breaks ELF alignment
requirements
   Product: binutils
   Version: 2.42 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: godlygeek at gmail dot com
  Target Milestone: ---

Created attachment 15278
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15278&action=edit
A patch to prevent this issue by dropping the unneeded PT_LOAD segment

Reproducer in the form of a published shared library (part of a Python
package):

mkdir /tmp/strip-bug
cd /tmp/strip-bug
wget
https://files.pythonhosted.org/packages/33/6d/bc85b76c79db078597e057a1022b9e5eadebb083840a2942d0cdd0100cb7/memray-1.11.0-cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
unzip
memray-1.11.0-cp38-cp38-manylinux_2_12_x86_64.manylinux2010_x86_64.whl
ldd memray/_memray.cpython-38-x86_64-linux-gnu.so
strip memray/_memray.cpython-38-x86_64-linux-gnu.so
ldd memray/_memray.cpython-38-x86_64-linux-gnu.so

The first call to `ldd` will output:

linux-vdso.so.1 (0x7ffc3583b000)
liblz4-c29043df.so.1.7.1 =>
/tmp/strip-bug/memray/../memray.libs/liblz4-c29043df.so.1.7.1
(0x7f2898b7e000)
libunwind-92483c07.so.8.0.1 =>
/tmp/strip-bug/memray/../memray.libs/libunwind-92483c07.so.8.0.1
(0x7f2898964000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f289894d000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f289876b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f289861c000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f28985ff000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f28985dc000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f28983ea000)
/lib64/ld-linux-x86-64.so.2 (0x7f28990a7000)

The second call, after stripping, will output:

not a dynamic executable

The issue appears to be caused by segment 8 (0-based, as reported by `readelf
-eW`). For the original shared library, that segment is reported as:

  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz
  Flg Align
  LOAD   0x878000 0x002ff000 0x002ff000 0x00d498
0x00d498 RW  0x1000

After `strip`, that segment shows up as:

  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz
  Flg Align
  LOAD   0x0f6cfc 0x002ff000 0x002ff000 0x00
0x00 RW  0x1000

The file size and memory size have both been dropped to 0, but the alignment
was not dropped from 0x1000 to 0x1, and so the assigned offset of 0x0f6cfc is
incompatible with the declared alignment. This occurs even when compiled from
`master`.

A patch is attached showing a possible solution to this issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/31208] strip with no arguments sometimes breaks ELF alignment requirements

[godlygeek at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31208

--- Comment #1 from Matt Wozniski  ---
This may indicate that the fix for
https://sourceware.org/bugzilla/show_bug.cgi?id=25237 was insufficient to
address all cases.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug binutils/31208] strip with no arguments sometimes breaks ELF alignment requirements

[godlygeek at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31208

--- Comment #4 from Matt Wozniski  ---
> So how did that load segment get there?

I strongly suspect that it's the result of the ELF editing performed by
`auditwheel repair`, from https://github.com/pypa/auditwheel - though I haven't
dug in to confirm that for certain.

The error message that you get if you try to dlopen() the shared library after
having called `strip` on it is:

ELF load command address/offset not properly aligned

There's a lot of reports of that error message on Google for Python packages
that were packaged by `auditwheel repair`:

https://github.com/linuxdeploy/linuxdeploy/issues/204
https://github.com/marcelotduarte/cx_Freeze/issues/1048
https://github.com/scipy/scipy/issues/17438

etc, which certainly seems to point a finger in the direction of the common
Python packaging tools. Idiomatic pre-compiled Python libraries vendor their
shared library dependencies, and `auditwheel repair` is the tooling used to do
so (including renaming the vendored shared libraries to avoid version
collisions between Python packages, and editing the shared libraries themselves
to update the SONAME and DT_NEEDED to match the renamed libraries).

-- 
You are receiving this mail because:
You are on the CC list for the bug.