> why have .so files of fedora-packages executable permissions?
It would be reasonable for the kernel to deny mmap(,,PROT_EXEC,,fd,)
if the file which is open on fd lacks [an appropriate flavor of] __S_IEXEC in .st_mode.
Apparently many current linux kernels for *x86* do not make such a restriction,
but it would be OK if the kernel did so.
In the history of UNIX and linux, popular hardware has not always carefully
separated all instances of "read for use by instruction pipeline" from
"read for load to general register". For instance on the PDP-11,
the instruction "mov $0x1234,r0" is encoded as
mov (pc)+,r0
.word 0x1234
and it is hard say whether the 0x1234 is in one class and not the other.
Thus separating PROT_EXEC from PROT_READ has been problematic.
Compilers also have been less-than-precise in this area, particularly for
jump tables, the characters in string constants, other literal values, etc.
There are good reasons why Harvard architecture (separate address spaces
for instructions and data) is often painful to use.
*x86* page-mapping and protection hardware does not provide completely-general
independent access capabilities for all modes (read * write * execute).
Other hardware does provide access capabilities which are more orthogonal,
such as PROT_EXEC completely independent of PROT_READ.
PowerPC may be such a case.
> they are not executable
Some are; libc.so.6 is an important case which demonstrates one use.
Generally, a shared library is just an ET_DYN file, and so can
have a non-zero ElfXX_Ehdr.e_entry. It is up to the author/maintainer
to decide that to do with the facility that ELF provides.
Most of the shared libraries in /lib{,64} *do* have a non-zero .e_entry.
(" readelf -h *.so | grep 'Entry point' ")
--
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
