Created attachment 1823578 [details] output from executing .so file Description of problem: Currently ALL .so files are executable even those without a valid entry point address. Version-Release number of selected component (if applicable): Tested on rhel 8.4, rhel 7.9 and fedora 34. How reproducible: very Steps to Reproduce: Attempt to launch any .so from the shell. /usr/lib64/libglib-2.0.so.0.6800.4 Segmentation fault (core dumped) /usr/lib64/libk5crypto.so.3.1 Segmentation fault (core dumped) /usr/lib64/libhogweed.so.6.4 Segmentation fault (core dumped) Actual results: SIGSEGV/core file is produced. Expected results: no SIGSEGV/core file Additional info: There is a separate kernel defect that was created to prevent the attempt to spawn a process of an .so with an e_entry == 0. https://bugzilla.redhat.com/show_bug.cgi?id=2004942 This defect is to actually set DSOs that don't have _start to have an e_entry of zero. This is because currently "Entry point address:" is non-zero on all DSO's even those without a _start which is leading to segfaults.
The decision to how to fail (either a core dump/segfault or execve() syscall failure or something else) is eventually a dynamic linker/kernel loader question. The ask here should be limited to having an option that sets the default e_entry (i.e. when there's no _start present or a custom address or symbol specified through -e) to 0.
(In reply to Siddhesh Poyarekar from comment #1) > The decision to how to fail (either a core dump/segfault or execve() syscall > failure or something else) is eventually a dynamic linker/kernel loader > question. The ask here should be limited to having an option that sets the > default e_entry (i.e. when there's no _start present or a custom address or > symbol specified through -e) to 0. Conceding to this comment, as all points are valid. But there is still absolutely a user experience aspect to this that I think we should take into account as well.
(In reply to Siddhesh Poyarekar from comment #1) > The ask here should be limited to having an option that sets the > default e_entry (i.e. when there's no _start present or a custom address or > symbol specified through -e) to 0. Is the ask that this should happen only when "-shared" has also been specified on the linker command line ? (Ie only when making shared libraries), or for any binary linked without an explicit start address ?
I think we need it mostly for -shared. If it's more convenient, we can probably teach GCC to pass -z nodefaultstart or something along with -shared. But changing the binutils default directly would be easier. Passing -e 0 with GCC for -shared might not work because it could override user settings.
(In reply to Florian Weimer from comment #4) > I think we need it mostly for -shared. If it's more convenient, we can > probably teach GCC to pass -z nodefaultstart or something along with > -shared. But changing the binutils default directly would be easier. No worries. I know how to adapt the linker. I am testing a local patch now...
OK, binutils-2.37-13.fc36 should have the change you want. I changed the linker so that when creating a binary with either the -r or -shared command line options enabled the heuristic for setting the start address will skip the step that tries the first address of the entry section. (The entry section is normally .text, but for ppc64le it is .opd). Can someone give it a try and update this BZ with the results ? Also - I have only made this change to the rawhide binutils. Do you want me to update F34 and F35 as well ? To me this is a new feature rather than a bug fix...
This change really has to go upstream first. And we'll need a companion kernel patch accepted, too.
(In reply to Florian Weimer from comment #7) > This change really has to go upstream first. I would still be interested to have any feedback from the updated rawhide binutils, but in the meantime I have proposed the patch upstream: https://sourceware.org/pipermail/binutils/2021-September/117966.html
Florian answered the needinfo question, so clearing the flag.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.