Bug 184446 - libstdc++ requires execmem priviledge on ppc platform
libstdc++ requires execmem priviledge on ppc platform
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Nick Clifton
: Reopened, Security
Depends On:
Blocks: 184590
  Show dependency treegraph
Reported: 2006-03-08 16:20 EST by Daniel Walsh
Modified: 2013-01-09 22:41 EST (History)
6 users (show)

See Also:
Fixed In Version: gcc-4.1.0-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-29 09:30:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
GCC patch that fixes the problem (1.59 KB, patch)
2006-03-09 18:08 EST, Alexandre Oliva
no flags Details | Diff
Patch that fixes the problem correctly :-) (784 bytes, patch)
2006-03-09 20:07 EST, Alexandre Oliva
no flags Details | Diff
Patch that fixes the bug in the linker (1.30 KB, patch)
2006-03-17 02:22 EST, Alexandre Oliva
no flags Details | Diff

  None (edit)
Description Daniel Walsh 2006-03-08 16:20:15 EST
Description of problem:
hpiod requires execmem on ppc platforms

SELinux will not allow it to start

It should not require this and probably has a build problem

Comment 2 Tim Waugh 2006-03-09 12:35:25 EST
[root@dhcp83-81 sbin]# eu-readelf -l /usr/lib/libstdc++.so.6 | grep LOAD
  LOAD           0x000000 0x00560000 0x00560000 0x108af8 0x108af8 R E 0x10000
  LOAD           0x109448 0x00679448 0x00679448 0x0061cc 0x00b9e8 RWE 0x10000
[root@dhcp83-81 sbin]# rpm -qf /usr/lib/libstdc++.so.6
Comment 5 Daniel Walsh 2006-03-09 13:27:08 EST
Tim do you have any idea what port it is trying to connect to?

Comment 6 Alexandre Oliva 2006-03-09 13:43:02 EST
.got and .plt contain executable code and are in the data segment on ppc32, and
this appears to be by design.  I found this comment in binutils-*/bfd/elf32-ppc.c:

/* The powerpc .got has a blrl instruction in it.  Mark it executable.  */

What I still haven't figured out is why there are shared libraries that do have
a GOT and a PLT, but do not get the executable bit set for them.  I noticed
libstdc++ and libgcj do get the bit set, whereas libgcc_s and libgcjawt don't.
Comment 7 Alexandre Oliva 2006-03-09 14:01:30 EST
Problem narrowed down to eh_globals.o in libsupc++, linking it by itself into a
dynamic library (-nostdlib) will get a library with an executable data segment.
 Now on to figure out why.
Comment 8 Alexandre Oliva 2006-03-09 15:01:03 EST
It uses a REL32 relocation to refer to _GLOBAL_OFFSET_TABLE_, which gets
htab->old_plt set, so we use the old layout that requires executable permission
on the GOT and the PLT.  It gets more confusing because simplifying that input
file to an empty function still caused the old GOT and PLT layouts to be
selected by default.

I suppose it's related with the use of TLS, let's see...
Comment 9 Alexandre Oliva 2006-03-09 18:08:48 EST
Created attachment 125909 [details]
GCC patch that fixes the problem

It was the TLS sequences, after all.  The code used to compute the address of
_GLOBAL_OFFSET_TABLE_ was regarded by the linker as requiring the old GOT/PLT
layout.  Many thanks to RTH for, erhm, being dragged into the problem when I
had to go pick up my daughter at school, and for coming up with the final
spelling of the patch.
Comment 10 Alexandre Oliva 2006-03-09 20:07:51 EST
Created attachment 125914 [details]
Patch that fixes the problem correctly :-)

As it turned out, GCC failed to build libmudflap with the previous patch :-(

Here's an even more conservative patch, that will use an additional dynamic
relocation in the TOC to compute the _GLOBAL_OFFSET_TABLE_ address.  prelink
should render that additional dynamic relocation a no-op, and we generate
smaller and faster code, so it's an overall win, except for non-prelinked
binaries, that take this small startup-time penalty.
Comment 11 Alexandre Oliva 2006-03-09 20:14:10 EST
For the record, the following packages/libraries in Core need rebuilding after
the GCC build is complete:

lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/cmd-mirror.so
lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/cmd-sleep.so
lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/liblftp-network.so
lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/liblftp-pty.so
lftp-3.4.2-4.ppc.rpm ./usr/lib/lftp/3.4.2/proto-file.so
lftp-3.4.2-4.ppc.rpm ./usr/lib/liblftp-jobs.so.0.0.0
lftp-3.4.2-4.ppc.rpm ./usr/lib/liblftp-tasks.so.0.0.0
libgcj-4.1.0-2.ppc.rpm ./usr/lib/libgcj.so.7.0.0
libmudflap-4.1.0-2.ppc.rpm ./usr/lib/libmudflapth.so.0.0.0
libstdc++-4.1.0-2.ppc.rpm ./usr/lib/libstdc++.so.6.0.8
libstdc++so7-4.2.0-0.3.20060203.1.ppc.rpm ./usr/lib/libstdc++-20060203.so.7.0.0
libwvstreams-4.2.1-1.2.ppc.rpm ./usr/lib/libwvbase.so.4.2
mono-core- ./usr/lib/libmono.so.0.0.0
numactl-0.6.4-1.26.2.ppc.rpm ./usr/lib/libnuma.so.1

Testing the new patch revealed that, if you take an object file compiled with
-fPIC that accesses locally-defined thread-local variables, and link that into a
main executable, the linker will relax the dynamic access models incorrectly. 
This is true with the code we generated after the patch, but it was already true
with the code we generated before, so I take it that this other error is not a
blocker.  I'll clone that into a separate bug and then try to address it as well.

This linker failure does not affect in any way the fix that goes into GCC, since
the GCC failure was only observed in dynamic libraries, and the linker failure
only affects main executables (it's the local exec access model that breaks).

It might turn out that it is not a linker problem, but rather a glibc problem,
if the segmentation fault is not because the relaxed code computes the wrong
address for the variable, but rather that say glibc fails to map the portion of
the stack reserved for the Static TLS block as readable or something like that.
 Very unlikely, but I thought I'd point out the possibility, just to test how
long people can hold their breaths ;-)
Comment 12 Alexandre Oliva 2006-03-17 02:22:43 EST
Created attachment 126265 [details]
Patch that fixes the bug in the linker

As it turned out, Alan Modra decided the linker was in error for considering
the code sequence emitted by GCC as a request for old GOT, so we should revert
the GCC change and update binutils with this patch, arranging for the GCC
update to require this updated binutils, at least on ppc.
Comment 13 Red Hat Bugzilla 2007-02-05 14:12:41 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 14 Bug Zapper 2008-04-03 13:06:27 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 15 Lubomir Kundrak 2008-04-08 16:00:18 EDT
Final Freeze is in effect now. Security fixes almost certainly warrant a freeze
break, so in case you build a fix for this, mail release engineering as
described here: [2]

[1] https://www.redhat.com/archives/fedora-devel-announce/2008-April/msg00007.html
[2] http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy

Comment 16 Bug Zapper 2008-05-13 22:06:33 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 17 Jesse Keating 2008-10-28 11:07:50 EDT
Hrm, this is a very old bug, was it ever fixed for 9, or still present in 10?
Comment 18 Daniel Walsh 2008-10-29 09:30:17 EDT
I have not heard about it again, I will close it for now and see if it comes back.

Note You need to log in before you can comment on or make changes to this bug.