The specific issue is that patchelf on a non-PIE binary can shift the base load address of the image forward, which on riscv64 falls afoul of mmap_min_addr, manifesting as an EPERM from ld-linux.so and a segfault.
The impact is fairly narrow because most Ubuntu binaries are PIE, but Python's debian/rules explicitly disables it. Other architectures are also basically immune due to luck: amd64 tends to base images up at 0x400000 while mmap_min_addr is still 0x10000, while armhf/arm64 base images at 0x10000 like riscv64 but their mmap_min_addr is down at 0x8000 for unclear reasons. This means that shifting the ELF header back a few bytes before the usual image base only breaks on riscv64, but it's by no means riscv64's fault. patchelf already kind of has code to handle this situation: PIE binaries have a base of 0, so they use the shared library codepath which moves altered sections to the end of the image, rather than to before the start. That code hopelessly corrupts binaries that aren't based at 0, but it was easy enough to fix and it seems to work, though patchelf is still very dodgy and could do with cleanup. https://github.com/wgrant/patchelf/commit/9734c99f47ba2365825269a1f131e98a17c7c328 and https://github.com/wgrant/patchelf/commit/9edcd40f18c54bd1c92ef1b7a518abc5bc8a9290 together at least get a working snapcraft, but I'm still testing more extensively. ** Also affects: patchelf (Ubuntu) Importance: Undecided Status: New ** Summary changed: - python3.8 from a riscv64 snap fails to run + patchelf creates unloadable non-PIE riscv64 executables -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1943963 Title: patchelf creates unloadable non-PIE riscv64 executables To manage notifications about this bug go to: https://bugs.launchpad.net/snapcraft/+bug/1943963/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
