I noticed that building this: ``` int x; int f (void) { return x; } ``` with: gcc `rpm --eval "%build_cflags %build_ldflags"` -m32 -fno-pic t.c -shared still produces an executable. There is a warning: /usr/bin/ld: warning: creating DT_TEXTREL in a shared object But exit status is zero, and there is an output file. I think we should ban text relocations in the same way we banned RWX segments. This is probably an item for after the mass rebuild. Reproducible: Always
Fixed in binutils-2.45.50-15.fc44 More specifically I have added a definable option to the binutils.spec file: # Enable the creation of relocations against the contents of read-only # sections (such as .text). This is a security vulnerability, so it is # disabled here by default. # Note - the upstream GNU Binutils sources enable the generation of this # kind of relocation by default, so this is a difference between Fedora # and upstream. %define enable_textrel 0
Just noting this broke ghc on i686. Though I have a new patch in hand to remove a hack that causes it (see bug 2430571). It may also have affected fpc.
FYI - for any future readers of this ticket: The simplest way to stop the linker from issuing this error message is to add "-Wl,-z,notext" to the command line.
(In reply to Nick Clifton from comment #1) > Fixed in binutils-2.45.50-15.fc44 > > More specifically I have added a definable option to the binutils.spec file: > > # Enable the creation of relocations against the contents of read-only > # sections (such as .text). This is a security vulnerability, so it is > # disabled here by default. > # Note - the upstream GNU Binutils sources enable the generation of this > # kind of relocation by default, so this is a difference between Fedora > # and upstream. > %define enable_textrel 0 how we disable this security feature ? , VirtualBox , x264 , fffmpeg and x265 have this warning: relocation in read-only section `.text'
(In reply to Sergio Basto from comment #4) > how we disable this security feature ? Add "-Wl,-z,notext" to the compiler command line. Ideally if you do add this option, it would be good to also include a comment as to why it is needed. Being able to modify read-only sections of an executable, especially the code, at run time is an obvious vulnerability. So there really should be a good reason for allowing it. Or at least a reason why the code being vulnerable is not going to affect the system as a whole.
*** Bug 2436257 has been marked as a duplicate of this bug. ***
In ffmpeg and libass, this may be connected to nasm-generated code, but only on i686. https://koji.fedoraproject.org/koji/taskinfo?taskID=142127825 https://koji.fedoraproject.org/koji/taskinfo?taskID=142127835
RPMFusion fixes are https://github.com/rpmfusion/ffmpeg/commit/3d0997d12c6a448cdcdfcb6b95bbf52dad3de43f https://github.com/rpmfusion/x264/commit/674b9662426993c59500fea244553da269470473
This seems to be affecting i686 builds of openh264 also, and I think for the same reason (nasm generated code)