[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240705211232.2718532-1-mmayer@broadcom.com>
Date: Fri, 5 Jul 2024 14:12:27 -0700
From: Markus Mayer <mmayer@...adcom.com>
To: Musl Mailing List <musl@...ts.openwall.com>
Cc: Markus Mayer <mmayer@...adcom.com>,
Colin Cross <ccross@...gle.com>
Subject: [PATCH 0/1] Ignore incorrect elf architecture libraries
Hi all,
Several months back, I reported a problem I discovered when it comes to
how musl's shared library loader is handling shared libraries of a wrong
architecture.[1] Colin Cross then responded that he had sent a patch for
the very same issue a year prior.[2]
There seemed to be some interest in my submission initially, but then
the discussion fizzled out.
The short summary of the problem is that the shared library loader will
stop looking for a suitable shared library once it finds a library of
the correct name. It won't care if it's the wrong architecture (ELF
class) and stop looking, regardless. The correct library will never be
found, even if present. This will result in binaries failing to run even
though they could have been executed without a problem.
If was finally able to get back to it and create this proposal.
I applied Colin's patch to musl 1.2.5 and experimented with it. I also
ran a bunch of tests. It seems to be doing exactly what I would expect
the shared library loader to do.
Since Colin's patch is much better than mine, I would like to re-submit
his patch and propose it for inclusion once more.
I am not entirely sure how to properly submit another person's patch to
the musl project. In kernel land, one would add Signed-off-by and
Tested-by tags to the commit message, but neither seem to be customary
in the musl project.
Please let me know what you think and if there is anything else I should
be doing to help with having this patch accepted.
To conclude the matter, I'll show the test setup I used.
* A simple test program linked against libz.so, built for aarch64.
* /usr/lib/libz.so being the aarch64 library
* /tmp/lib/libz.so being the aarch32 library
And these are the tests:
* Run "zdemo" without setting LD_LIBRARY_PATH
* Run "zdemo" with LD_LIBRARY_PATH pointing to /tmp/lib
* Repeat the steps with and without Colin's patch
$ ls -l /tmp/lib
total 100
drwxr-xr-x 2 root root 100 Jan 7 04:18 .
drwxrwxrwt 3 root root 120 Jan 7 04:18 ..
lrwxrwxrwx 1 root root 13 Jul 5 2024 libz.so -> libz.so.1.3.1
lrwxrwxrwx 1 root root 13 Jul 5 2024 libz.so.1 -> libz.so.1.3.1
-rwxr-xr-x 1 root root 101420 Jul 5 2024 libz.so.1.3.1
$ ls -l /usr/lib/libz*
lrwxrwxrwx 1 root root 13 Jun 28 2024 libz.so -> libz.so.1.3.1
lrwxrwxrwx 1 root root 13 Jun 28 2024 libz.so.1 -> libz.so.1.3.1
-rwxr-xr-x 1 root root 83664 Jun 28 2024 libz.so.1.3.1
The results look like this.
1) Unpatched libc, no LD_LIBRARY_PATH:
$ ./zdemo-arm64 /dev/null
gz=0x7fae7f4860
2) Unpatched libc, with LD_LIBRARY_PATH:
$ LD_LIBRARY_PATH=/tmp/lib ./zdemo-arm64 /dev/null
Error loading shared library libz.so.1: Exec format error (needed by ./zdemo-arm64)
Error relocating ./zdemo-arm64: gzopen: symbol not found
Error relocating ./zdemo-arm64: gzclose: symbol not found
3) Patched libc, no LD_LIBRARY_PATH:
$ ./libc.so ./zdemo-arm64 /dev/null
gz=0x7faca58860
4) Patched libc, with LD_LIBRARY_PATH:
$ LD_LIBRARY_PATH=/tmp/lib ./libc.so ./zdemo-arm64 /dev/null
gz=0x7f9002d860
4a) Patched libc, with LD_LIBRARY_PATH and debug output:
$ LD_LIBRARY_PATH=/tmp/lib ./libc.so ./zdemo-arm64 /dev/null
verify_elf_arch, 712: machine=b7 / EI_CLASS=2
path_open_library, 920: opening /tmp/lib/libz.so.1
verify_elf_arch, 712: machine=28 / EI_CLASS=1
path_open_library, 920: opening /lib/libz.so.1
open failed -- No such file or directory
path_open_library, 920: opening /usr/local/lib/libz.so.1
open failed -- No such file or directory
path_open_library, 920: opening /usr/lib/libz.so.1
verify_elf_arch, 712: machine=b7 / EI_CLASS=2
path_open_library, 956: returning 3 (for /usr/lib/libz.so.1)
verify_elf_arch, 712: machine=b7 / EI_CLASS=2
gz=0x7f9002d860
As we can see, with Colin's patch, it finds /tmp/lib/libz.so.1 first,
realizes it's the wrong ELF class -- and keeps looking. It then proceeds
through the regular library search path (/lib, /usr/local/lib,
/usr/lib), where it ultimately finds the proper libz.
Without Colin's patch, it bails after trying to use /tmp/lib/libz.so.1.
Regards,
-Markus
[1] https://www.openwall.com/lists/musl/2024/02/07/1
[2] https://www.openwall.com/lists/musl/2023/02/07/3
Colin Cross (1):
Ignore incorrect elf architecture libraries
ldso/dynlink.c | 77 +++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 61 insertions(+), 16 deletions(-)
--
2.45.2
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
