The "which" utility has a text relocation, which is trivial to remove. According to the grsecurity kernel patches, for the future progress of PaX, it is useful to eliminate these where possible. The "which" utility is used a lot, not just by users but also by various common scripts, so it's a text relocation worth eliminating. The relocation comes from the use of "xmalloc" in libiberty.a. There is already a configure option to disable use of libiberty; setting this builds "which" with its own internal version of xmalloc (using malloc). Adding the following to the 2.16 ebuild script in the appropriate places can work: myconf="" src_compile() { use notextrel \ && myconf="${myconf} --disable-iberty" econf \ ${myconf} || die emake || die } Obviously I've invented a new use flag here, for the purposes of testing. Perhaps using the existing flag "hardened" instead might be better; although it does dilute the meaning of "hardened". It may be that future versions of libiberty.a avoid this anyway (which would be nice). Reproducible: Always Steps to Reproduce: 1.readelf -d /usr/bin/which 2. 3. Actual Results: contains a TEXTREL element Expected Results: had no text relocation elements :)
>>> sys-apps/which-2.16 merged. ... solar@simple ~ $ readelf -d `which which` | grep TEXTREL I'm not seeing any TEXTREL's in which here. qpkg -f /usr/lib/libiberty.a sys-devel/binutils * What version of binutils are you using and with what USE flags? I'm using sys-devel/binutils-2.15.90.0.1.1-r3 -bootstrap -build -debug +multitarget -nls 0 kB (perhaps nls = root cause?)
Just checked on my other machine, and "which" doesn't have a TEXTREL there. I have binutils-2.14.90.8-r1 on both machines, with identical use flags (+nls -multitarget -uclibc -debug); the TEXTREL appeared on the p3 machine, and is not present on the amd machine. Hmm; just did an ebuild unpack on binutils-2.14.90.8-r1 on the p3 machine, and it downloaded the 1.3 version of the patches (implying that it didn't have these before), but still unpacked the 1.2 version of the patches. Did an ebuild clean and ebuild unpack again, and it's now picked up the 1.3 version of the patches! OK; I've re-emerged binutils (and which, without my hack) and the TEXTREL has gone. I guess it's either the patchset change, or a compiler difference. binutils was compiled with 3.3.3-r6 on the p3, with 3.3.2-r5 on the amd box, according to my emerge.log and genlop. I'm now using gcc 3.3.4-r1.
Assuming the problem was due to old and/or incompatible combinations of gcc, glibc etc, it has now no longer an issue.
Hmm; did an "emerge -e system" recently, and the textrel is back. Looking at the "readelf -a" output, it shows various symbols as R_386_32 instead of R_386_GLOB_DAT (stderr, environ). On my other machine, there are no textrels, and the symbols are R_386_GLOB_DAT only. I'll attach the readelf -a output.
Created attachment 43272 [details] readelf -a /usr/bin/which outptu
Created attachment 43273 [details] readelf -a output for laptop which (no textrel) for comparison
Still a problem?
[ebuild R ] sys-apps/procps-3.2.3-r1 0 kB amd64 gcc # ps Bounds Checking GCC v gcc-3.4.2-3.2 Copyright (C) 1995 Richard W.M. Jones Bounds Checking comes with ABSOLUTELY NO WARRANTY. For details see file `COPYING' that should have come with the source to this program. Bounds Checking is free software, and you are welcome to redistribute it under certain conditions. See the file `COPYING' for details. For more information, set GCC_BOUNDS_OPTS to `-help' PID TTY TIME CMD 18344 ? 00:00:00 su 18345 ? 00:00:00 bash 20974 ? 00:00:00 bash 23030 ? 00:00:00 ps Bounds library call frequency statistics: Calls to push, pop, param function: 2045, 2045, 115 Calls to add, delete stack: 2917, 2917 Calls to add, delete heap: 26, 5 Calls to check pointer +/- integer: 15045 Calls to check array references: 11890 Calls to check pointer differences: 4883 Calls to check object references: 14212 Calls to check component references: 5821 Calls to check truth, falsity of pointers: 503, 6060 Calls to check <, >, <=, >= of pointers: 0 Calls to check ==, != of pointers: 5 Calls to check p++, ++p, p--, --p: 3530, 0, 101, 0 Calls to add, find, delete oob pointers: 0, 0, 0 References to unchecked static, stack: 1929, 114
Ignore comment #8 It was for bug #70371
Did an "emerge -e system" again, and it's gone. Since it's now appeared twice, I'd like to get to the bottom of it rather than just close it down, but it may take a while as I don't know exactly how to get it to happen again (I've setup portage logging now, so if it does I should have a record of the builds). In the meantime, I've set it to resolved/needinfo, so it doesn't show up in searches for unresolved bugs.
