[BZ 15846] As discussed in the recent thread on my $EXEC_ORIGIN patch
and in BZ 15846, getauxval() presently has no unambiguous way of
reporting an error condition. It currently returns zero on error, but
this may also be a valid result for some auxv entries. As there is no
clear invalid result for all current and future auxv entries, this patch
sets errno (following a suggestion in the BZ entry).
This version of the patch also adds documentation and tests for the
value-not-found conditions in getauxval().
This is a follow-on to the previous patch to support the ELFv2 ABI in the
dynamic loader, split off into its own patch since it is just an optional
optimization.
In the ELFv2 ABI, most functions define both a global and a local entry
point; the local entry requires r2 to be already set up by the caller
to point to the callee's TOC; while the global entry does not require
the caller to know about the callee's TOC, but it needs to set up r12
to the callee's entry point address.
Now, when setting up a PLT slot, the dynamic linker will usually need
to enter the target function's global entry point. However, if the
linker can prove that the target function is in the same DSO as the
PLT slot itself, and the whole DSO only uses a single TOC (which the
linker will let ld.so know via a DT_PPC64_OPT entry), then it is
possible to actually enter the local entry point address into the
PLT slot, for a slight improvement in performance.
Note that this uncovered a problem on the first call via _dl_runtime_resolve,
because that routine neglected to restore the caller's TOC before calling
the target function for the first time, since it assumed that function
would always reload its own TOC anyway ...
This patch adds support for the ELFv2 ABI feature to remove function
descriptors. See this GCC patch for in-depth discussion:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01141.html
This mostly involves two types of changes: updating assembler source
files to the new logic, and updating the dynamic loader.
After the refactoring in the previous patch, most of the assembler source
changes can be handled simply by providing ELFv2 versions of the
macros in sysdep.h. One somewhat non-obvious change is in __GI__setjmp:
this used to "fall through" to the immediately following __setjmp ENTRY
point. This is no longer safe in the ELFv2 since ENTRY defines both
a global and a local entry point, and you cannot simply fall through
to a global entry point as it requires r12 to be set up.
Also, makecontext needs to be updated to set up registers according to
the new ABI for calling into the context's start routine.
The dynamic linker changes mostly consist of removing special code
to handle function descriptors. We also need to support the new PLT
and glink format used by the the ELFv2 linker, see:
https://sourceware.org/ml/binutils/2013-10/msg00376.html
In addition, the dynamic linker now verifies that the dynamic libraries
it loads match its own ABI.
The hack in VDSO_IFUNC_RET to "synthesize" a function descriptor
for vDSO routines is also no longer necessary for ELFv2.
This patch updates glibc in accordance with the binutils patch checked in here:
https://sourceware.org/ml/binutils/2013-10/msg00372.html
This changes the various R_PPC64_..._HI and _HA relocations to report
32-bit overflows. The motivation is that existing uses of @h / @ha
are to build up 32-bit offsets (for the "medium model" TOC access
that GCC now defaults to), and we'd really like to see failures at
link / load time rather than silent truncations.
For those rare cases where a modifier is needed to build up a 64-bit
constant, new relocations _HIGH / _HIGHA are supported.
The patch also fixes a bug in overflow checking for the R_PPC64_ADDR30
and R_PPC64_ADDR32 relocations.
On hppa and ia64, the macro DL_AUTO_FUNCTION_ADDRESS() uses the
variable fptr[2] in it's own scope.
The content of fptr[] is thus undefined right after the macro exits.
Newer gcc's (>= 4.7) reuse the stack space of this variable triggering
a segmentation fault in dl-init.c:69.
To fix this we rewrite the macros to make the call directly to init
and fini without needing to pass back a constructed function pointer.
It was noted in 2005 (BZ #832), 2006 (BZ #3266), and 2007 [1] that ldd
fails on shells other than Bash >= 3.0 because of the pipefail option
around try_trace (added on 2004-12-08). EGLIBC was patched in 2008 [2]
(r6912) to make the pipefail check run only on shells that support it,
but RTLD output would still be lost on other shells with certain SELinux
policies.
This patch rewrites try_trace to work on any POSIX-conformant shell in
such a way as to also work with such SELinux policies. It also obviates
one difference between glibc and EGLIBC.
URL: https://sourceware.org/ml/libc-alpha/2007-01/msg00041.html
URL: http://www.eglibc.org/archives/patches/msg00526.html
2013-09-11 P. J. McDermott <pj@pehjota.net>
[BZ #832]
* elf/ldd.bash.in (try_trace): More robustly and portably work around
SELinux terminal write permissions by using a command substitution
instead of a pipeline and pipefail option.
Statically built binaries use __pointer_chk_guard_local,
while dynamically built binaries use __pointer_chk_guard.
Provide the right definition depending on the test case
we are building.
The pointer guard used for pointer mangling was not initialized for
static applications resulting in the security feature being disabled.
The pointer guard is now correctly initialized to a random value for
static applications. Existing static applications need to be
recompiled to take advantage of the fix.
The test tst-ptrguard1-static and tst-ptrguard1 add regression
coverage to ensure the pointer guards are sufficiently random
and initialized to a default value.
It has been a long practice for software using IEEE 754 floating-point
arithmetic run on MIPS processors to use an encoding of Not-a-Number
(NaN) data different to one used by software run on other processors.
And as of IEEE 754-2008 revision [1] this encoding does not follow one
recommended in the standard, as specified in section 6.2.1, where it
is stated that quiet NaNs should have the first bit (d1) of their
significand set to 1 while signalling NaNs should have that bit set to
0, but MIPS software interprets the two bits in the opposite manner.
As from revision 3.50 [2][3] the MIPS Architecture provides for
processors that support the IEEE 754-2008 preferred NaN encoding format.
As the two formats (further referred to as "legacy NaN" and "2008 NaN")
are incompatible to each other, tools have to provide support for the
two formats to help people avoid using incompatible binary modules.
The change is comprised of two functional groups of features, both of
which are required for correct support.
1. Dynamic linker support.
To enforce the NaN encoding requirement in dynamic linking a new ELF
file header flag has been defined. This flag is set for 2008-NaN
shared modules and executables and clear for legacy-NaN ones. The
dynamic linker silently ignores any incompatible modules it
encounters in dependency processing.
To avoid unnecessary processing of incompatible modules in the
presence of a shared module cache, a set of new cache flags has been
defined to mark 2008-NaN modules for the three ABIs supported.
Changes to sysdeps/unix/sysv/linux/mips/readelflib.c have been made
following an earlier code quality suggestion made here:
http://sourceware.org/ml/libc-ports/2009-03/msg00036.html
and are therefore a little bit more extensive than the minimum
required.
Finally a new name has been defined for the dynamic linker so that
2008-NaN and legacy-NaN binaries can coexist on a single system that
supports dual-mode operation and that a legacy dynamic linker that
does not support verifying the 2008-NaN ELF file header flag is not
chosen to interpret a 2008-NaN binary by accident.
2. Floating environment support.
IEEE 754-2008 features are controlled in the Floating-Point Control
and Status (FCSR) register and updates are needed to floating
environment support so that the 2008-NaN flag is set correctly and
the kernel default, inferred from the 2008-NaN ELF file header flag
at the time an executable is loaded, respected.
As the NaN encoding format is a property of GCC code generation that is
both a user-selected GCC configuration default and can be overridden
with GCC options, code that needs to know what NaN encoding standard it
has been configured for checks for the __mips_nan2008 macro that is
defined internally by GCC whenever the 2008-NaN mode has been selected.
This mode is determined at the glibc configuration time and therefore a
few consistency checks have been added to catch cases where compilation
flags have been overridden by the user.
The 2008 NaN set of features relies on kernel support as the in-kernel
floating-point emulator needs to be aware of the NaN encoding used even
on hard-float processors and configure the FPU context according to the
value of the 2008 NaN ELF file header flag of the executable being
started. As at this time work on kernel support is still in progress
and the relevant changes have not made their way yet to linux.org master
repository.
Therefore the minimum version supported has been artificially set to
10.0.0 so that 2008-NaN code is not accidentally run on a Linux kernel
that does not suppport it. It is anticipated that the version is
adjusted later on to the actual initial linux.org kernel version to
support this feature. Legacy NaN encoding support is unaffected, older
kernel versions remain supported.
[1] "IEEE Standard for Floating-Point Arithmetic", IEEE Computer
Society, IEEE Std 754-2008, 29 August 2008
[2] "MIPS Architecture For Programmers, Volume I-A: Introduction to the
MIPS32 Architecture", MIPS Technologies, Inc., Document Number:
MD00082, Revision 3.50, September 20, 2012
[3] "MIPS Architecture For Programmers, Volume I-A: Introduction to the
MIPS64 Architecture", MIPS Technologies, Inc., Document Number:
MD00083, Revision 3.50, September 20, 2012
Long ago static startup did not parse the auxiliary vector and therefore
could not get at any `AT_FPUCW' tag to check whether upon FPU context
allocation the kernel would use a FPU control word setting different to
that provided by the `__fpu_control' variable. Static startup therefore
always initialized the FPU control word, forcing immediate FPU context
allocation even for binaries that otherwise never used the FPU.
As from GIT commit f8f900ecb9 static
startup supports parsing the auxiliary vector, so now it can avoid
explicit initialization of the FPU control word, just as can dynamic
startup, in the usual case where the setting written to the FPU control
word would be the same as the kernel uses. This defers FPU context
allocation until the binary itself actually pokes at the FPU.
Note that the `AT_FPUCW' tag is usually absent from the auxiliary vector
in which case _FPU_DEFAULT is assumed to be the kernel default.
This change creates a link map in static executables to serve as the
global search list for dlopen. It fixes a problem with the inability
to access the global symbol object and a crash on an attempt to map a
DSO into the global scope. Some code that has become dead after the
addition of this link map is removed too and test cases are provided.
Resolves: #15465
The program name may be unavailable if the user application tampers
with argc and argv[]. Some parts of the dynamic linker caters for
this while others don't, so this patch consolidates the check and
fallback into a single macro and updates all users.
In dl-hwcaps.c the comment read that rounding was done
to ElfW(Addr), but it's actually rounded to ElfW(Word).
In ldconfig.c we make each comment a sentence and
mention that the "tls" pseudo-hwcap is just for legacy
installations where TLS was optional.
---
2013-05-22 Carlos O'Donell <carlos@redhat.com>
* elf/ldconfig.c (is_hwcap_platform): Make comments full setences.
(main): Mention "tls" pseudo-hwcap is legacy.
* elf/dl-hwcaps.c (_dl_important_hwcaps): Correct rounding comment.
Loading of the vDSO pseudo-hwcap from the type 2 GNU note is
a rather arcane and poorly documented process. Given that I had
a chance to review this code today I thought I would add all
of the things I had to lookup to verify the validity of the
process.
With a single .note.GNU the vDSO can register up to 64 flags,
though in practice you are limited to 64 - _DL_FIRST_EXTRA
bits which on x86 is 12 bits.
The only use of this that I know of is in the Xen support
in Linux where they use the 1st bit to indicate "nosegneg".
I see "We use bit 1 to avoid bugs in some versions of glibc
when bit 0 is used; the choice is otherwise arbitrary.", but
no reference to a glibc bug anywhere. The code as-is should
support bit zero, so we still have that free for future use.
The kernel, glibc, and ld.so.cache must coordinate to ensure
that bit values don't go too high and are used consistently.
---
2013-05-13 Carlos O'Donell <carlos@redhat.com>
* elf/dl-hwcaps.c (_dl_important_hwcaps): Comment vDSO hwcap loading.
* elf/ldconfig.c (is_hwcap_platform): Comment each hwcap check.
(main): Comment "tls" pseudo-hwcap.
The algorithm for scanning dependencies upon dlclose is
less than immediately obvious. This patch adds two bits
of comments that explain why you start the dependency
search at l_initfini[1], and why you need to restart
the search.
---
2013-05-09 Carlos O'Donell <carlos@redhat.com>
* elf/dl-close.c (_dl_close_worker): Add comments.
The seen array was doubled in size recently, but the memset to clear
the array was not adjusted. We adjust the memset to always be correct
regardless of the size of seen.
---
2013-04-06 Carlos O'Donell <carlos@redhat.com>
[BZ #15309]
* elf/dl-open.c (dl_open_worker): memset all of seen array.
These prototypes are duplicated in many places. Add a dedicated
header for holding prototypes for program-specific functions to
avoid that.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
ARM now supports loading unmarked objects from
the dynamic loader cache. Unmarked objects can
be used with the hard-float or soft-float ABI.
We must support loading unmarked objects during
the transition period from a binutils that does
not mark objects to one that does mark them with
the correct ELF flags.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
We setup $(READELF) and use it everywhere, so fix the two places
that were using readelf directly.
Reported-by: Denis M. <god@politeia.in>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
* sysdeps/generic/ldconfig.h (FLAG_AARCH64_LIB64): New macro.
* elf/cache.c (print_entry): Print ",AArch64" for
FLAG_AARCH64_LIB64.
Signed-off-by: Steve McIntyre <steve.mcintyre@linaro.org>
Reviewed-by: Carlos O'Donell <carlos@systemhalted.org>
* sysdeps/generic/ldconfig.h (FLAG_ARM_LIBHF): New macro.
* elf/cache.c (print_entry): Print ",hard-float" for
FLAG_ARM_LIBHF.
Signed-off-by: Steve McIntyre <steve.mcintyre@linaro.org>
Reviewed-by: Carlos O'Donell <carlos@systemhalted.org>
This hook is useful for any arch-specific functionality that
should be done on loaded objects. For the tile architecture,
the hook is already provided (though we switch to using the new
macro name with this commit) and implements a simulator notifier
so that the simulator can load Elf symbols to match the object
and generate better error messages for PC's.
Also, remove a spurious definition of DL_UNMAP in dl-runtime.c
* elf/Makefile (tests): Remove conditional for have-initfini-array
since this is now always required and the variable does not exist
anymore.
(tests-static): Likewise.
(modules-names): Likewise.
* elf/tst-array1.c (fini_array): Make writeable so that it can be
merged with constructor/destructor.
(init_array): Likewise.
* elf/tst-array2dep.c (fini_array): Likewise.
(init_array): Likewise.
Commit glibc-2.14~10 disallowed rtld self loading to avoid a segfault
that used to happen when rtld was loading itself in normal mode.
Unfortunately, that commit disallowed all modes of self loading,
including those that used to work before. This change limits the check
for self loading to normal mode only, so that instruments like ldd could
handle rtld properly.
* csu/libc-tls.c (static_dtv): Renamed to ...
(_dl_static_dtv): This. Make it global.
(_dl_initial_dtv): Removed.
(__libc_setup_tls): Updated.
* elf/dl-tls.c (DL_INITIAL_DTV): New macro.
(_dl_deallocate_tls): Replace GL(dl_initial_dtv) with
DL_INITIAL_DTV.
When unmapping the first object in a namespace, the runtime linker
did not update the externally visible pointer. This resulted in
debuggers seeing pointers to memory that had been freed.
Add support for STT_GNU_IFUNC symbols and the new R_390_IRELATIVE
relocation. Provide optimized version of memcpy, memset, and memcmp
for z10 and z196.
[BZ #13579] Do not free l_initfini and allow it to be reused
on subsequent dl_open calls for the same library. This fixes
the invalid memory access in do_lookup_x when the previously
free'd l_initfini was accessed through l_searchlist when a
library had been opened for the second time.
[BZ #13882]
* elf/dl-deps.c (_dl_map_object_deps): Fix cycle detection. Use
uint16_t for elements in the "seen" array to avoid char overflows.
* elf/dl-fini.c (_dl_sort_fini): Likewise.
* elf/dl-open.c (dl_open_worker): Likewise.
When a stack is marked executable due to loading a DSO that requires
an executable stack, the logic tends to leave out a portion of stack
after the first frame, thus causing a difference in the value returned
by pthread_getattr_np before and after the stack is marked
executable. It ought to be possible to fix this by marking the rest of
the stack as executable too, but in the interest of marking as less of
the stack as executable as possible, the path this fix takes is to
make pthread_getattr_np also look at the first frame as the underflow
end of the stack and compute size and stack top accordingly.
The above happens only for the main process stack. NPTL thread stacks
are not affected by this change.
