Nicholas Piggin [Thu, 20 May 2021 14:00:36 +0000 (11:00 -0300)]
powerpc: Fix handling of scv return error codes [BZ #27892]
When using scv for templated ASM syscalls, current code interprets any
negative return value as error, but the only valid error codes are in
the range -4095..-1 according to the ABI.
This commit also fixes 'signal.gen.test' strace test, where the issue
was first identified.
nptl_db: Support different libpthread/ld.so load orders (bug 27744)
libthread_db is loaded once GDB encounters libpthread, and at this
point, ld.so may not have been processed by GDB yet. As a result,
_rtld_global cannot be accessed by regular means from libthread_db.
To make this work until GDB can be fixed, acess _rtld_global through
a pointer stored in libpthread.
The new test does not reproduce bug 27744 with
--disable-hardcoded-path-in-tests, but is still a valid smoke test.
With --enable-hardcoded-path-in-tests, it is necessary to avoid
add-symbol-file because this can tickle a GDB bug.
Szabolcs Nagy [Tue, 2 Feb 2021 15:02:09 +0000 (15:02 +0000)]
Remove PR_TAGGED_ADDR_ENABLE from sys/prctl.h
The value of PR_TAGGED_ADDR_ENABLE was incorrect in the installed
headers and the prctl command macros were missing that are needed
for it to be useful (PR_SET_TAGGED_ADDR_CTRL). Linux headers have
the definitions since 5.4 so it's widely available, we don't need
to repeat these definitions. The remaining definitions are from
Linux 5.10.
To build glibc with --enable-memory-tagging, Linux 5.4 headers and
binutils 2.33.1 or newer is needed.
Fix SXID_ERASE behavior in setuid programs (BZ #27471)
When parse_tunables tries to erase a tunable marked as SXID_ERASE for
setuid programs, it ends up setting the envvar string iterator
incorrectly, because of which it may parse the next tunable
incorrectly. Given that currently the implementation allows malformed
and unrecognized tunables pass through, it may even allow SXID_ERASE
tunables to go through.
This change revamps the SXID_ERASE implementation so that:
- Only valid tunables are written back to the tunestr string, because
of which children of SXID programs will only inherit a clean list of
identified tunables that are not SXID_ERASE.
- Unrecognized tunables get scrubbed off from the environment and
subsequently from the child environment.
- This has the side-effect that a tunable that is not identified by
the setxid binary, will not be passed on to a non-setxid child even
if the child could have identified that tunable. This may break
applications that expect this behaviour but expecting such tunables
to cross the SXID boundary is wrong. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit 2ed18c5b534d9e92fc006202a5af0df6b72e7aca)
Instead of passing GLIBC_TUNABLES via the environment, pass the
environment variable from parent to child. This allows us to test
multiple variables to ensure better coverage.
The test list currently only includes the case that's already being
tested. More tests will be added later. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit 061fe3f8add46a89b7453e87eabb9c4695005ced)
tst-env-setuid: Use support_capture_subprogram_self_sgid
Use the support_capture_subprogram_self_sgid to spawn an sgid child. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit ca335281068a1ed549a75ee64f90a8310755956f)
Add a new function support_capture_subprogram_self_sgid that spawns an
sgid child of the running program with its own image and returns the
exit code of the child process. This functionality is used by at
least three tests in the testsuite at the moment, so it makes sense to
consolidate.
There is also a new function support_subprogram_wait which should
provide simple system() like functionality that does not set up file
actions. This is useful in cases where only the return code of the
spawned subprocess is interesting.
This patch also ports tst-secure-getenv to this new function. A
subsequent patch will port other tests. This also brings an important
change to tst-secure-getenv behaviour. Now instead of succeeding, the
test fails as UNSUPPORTED if it is unable to spawn a setgid child,
which is how it should have been in the first place. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
(cherry picked from commit 716a3bdc41b2b4b864dc64475015ba51e35e1273)
The simplification of tunable_set interfaces took care of
signed/unsigned conversions while setting values, but comparison with
bounds ended up being incorrect; comparing TUNABLE_SIZE_T values for
example will fail because SIZE_MAX is seen as -1.
Add comparison helpers that take tunable types into account and use
them to do comparison instead.
linux: Normalize and return timeout on select (BZ #27651)
The commit 2433d39b697, which added time64 support to select, changed
the function to use __NR_pselect6 (or __NR_pelect6_time64) on all
architectures. However, on architectures where the symbol was
implemented with __NR_select the kernel normalizes the passed timeout
instead of return EINVAL. For instance, the input timeval
{ 0, 5000000 } is interpreted as { 5, 0 }.
And as indicated by BZ #27651, this semantic seems to be expected
and changing it results in some performance issues (most likely
the program does not check the return code and keeps issuing
select with unormalized tv_usec argument).
To avoid a different semantic depending whether which syscall the
architecture used to issue, select now always normalize the timeout
input. This is a slight change for some ABIs (for instance aarch64).
Lukasz Majewski [Sat, 13 Mar 2021 22:34:21 +0000 (23:34 +0100)]
tst: Provide test for select
This change adds new test to assess select()'s timeout related
functionality (the rdfs set provides valid fd - stderr - but during
normal program operation there is no data to be read, so one just
waits for timeout).
To be more specific - two use cases are checked:
- if select() times out immediately when passed struct timeval has
zero values of tv_usec and tv_sec.
- if select() times out after timeout specified in passed argument
Szabolcs Nagy [Thu, 25 Feb 2021 14:49:58 +0000 (14:49 +0000)]
malloc: Fix a realloc crash with heap tagging [BZ 27468]
_int_free must be called with a chunk that has its tag reset. This was
missing in a rare case that could crash when heap tagging is enabled:
when in a multi-threaded process the current arena runs out of memory
during realloc, but another arena still has space to finish the realloc
then _int_free was called without clearing the user allocation tags.
Stefan Liebler [Tue, 23 Mar 2021 16:29:26 +0000 (17:29 +0100)]
S390: Also check vector support in memmove ifunc-selector [BZ #27511]
The arch13 memmove variant is currently selected by the ifunc selector
if the Miscellaneous-Instruction-Extensions Facility 3 facility bit
is present, but the function is also using vector instructions.
If the vector support is not present, one is receiving an operation
exception.
Therefore this patch also checks for vector support in the ifunc
selector and in ifunc-impl-list.c.
Just to be sure, the configure check is now also testing an arch13
vector instruction and an arch13 Miscellaneous-Instruction-Extensions
Facility 3 instruction.
DJ Delorie [Thu, 11 Mar 2021 17:50:02 +0000 (12:50 -0500)]
test-container: Always copy test-specific support files [BZ #27537]
There's a small chance that a fresh checkout will result in some of
the test-specific container files will have the same timestamp and
size, which breaks the rsync logic in test-container, resulting in
tests running with the wrong support files.
This patch changes the rsync logic to always copy the test-specific
files, which normally would always be copied anyway. The rsync logic
for the testroot itself is unchanged.
It is effectively used, unexcept for pthread_cond_destroy, where we do
not want it; see bug 27304. The internal locks do not support a
process-shared mode.
Jakub Jelinek [Thu, 4 Mar 2021 14:15:33 +0000 (15:15 +0100)]
pthread_once hangs when init routine throws an exception [BZ #18435]
This is another attempt at making pthread_once handle throwing exceptions
from the init routine callback. As the new testcases show, just switching
to the cleanup attribute based cleanup does fix the tst-once5 test, but
breaks the new tst-oncey3 test. That is because when throwing exceptions,
only the unwind info registered cleanups (i.e. C++ destructors or cleanup
attribute), when cancelling threads and there has been unwind info from the
cancellation point up to whatever needs cleanup both unwind info registered
cleanups and THREAD_SETMEM (self, cleanup, ...) registered cleanups are
invoked, but once we hit some frame with no unwind info, only the
THREAD_SETMEM (self, cleanup, ...) registered cleanups are invoked.
So, to stay fully backwards compatible (allow init routines without
unwind info which encounter cancellation points) and handle exception throwing
we actually need to register the pthread_once cleanups in both unwind info
and in the THREAD_SETMEM (self, cleanup, ...) way.
If an exception is thrown, only the former will happen and we in that case
need to also unregister the THREAD_SETMEM (self, cleanup, ...) registered
handler, because otherwise after catching the exception the user code could
call deeper into the stack some cancellation point, get cancelled and then
a stale cleanup handler would clobber stack and probably crash.
If a thread calling init routine is cancelled and unwind info ends before
the pthread_once frame, it will be cleaned up through self->cleanup as
before. And if unwind info is present, unwind_stop first calls the
self->cleanup registered handler for the frame, then it will call the
unwind info registered handler but that will already see __do_it == 0
and do nothing.
Florian Weimer [Mon, 15 Mar 2021 09:33:43 +0000 (10:33 +0100)]
elf: ld.so --help calls _dl_init_paths without a main map [BZ #27577]
In this case, use the link map of the dynamic loader itself as
a replacement. This is more than just a hack: if we ever support
DT_RUNPATH/DT_RPATH for the dynamic loader, reporting it for
ld.so --help (without further command line arguments) would be the
right thing to do.
Carlos O'Donell [Fri, 12 Mar 2021 15:44:47 +0000 (16:44 +0100)]
elf: Always set l in _dl_init_paths (bug 23462)
After d1d5471579eb0426671bf94f2d71e61dfb204c30 ("Remove dead
DL_DST_REQ_STATIC code.") we always setup the link map l to make the
static and shared cases the same. The bug is that in elf/dl-load.c
(_dl_init_paths) we conditionally set l only in the #ifdef SHARED
case, but unconditionally use it later. The simple solution is to
remove the #ifdef SHARED conditional, because it's no longer needed,
and unconditionally setup l for both the static and shared cases. A
regression test is added to run a static binary with
LD_LIBRARY_PATH='$ORIGIN' which crashes before the fix and runs after
the fix.
x86: Move x86 processor cache info to cpu_features
missed _SC_LEVEL1_ICACHE_LINESIZE.
1. Add level1_icache_linesize to struct cpu_features.
2. Initialize level1_icache_linesize by calling handle_intel,
handle_zhaoxin and handle_amd with _SC_LEVEL1_ICACHE_LINESIZE.
3. Return level1_icache_linesize for _SC_LEVEL1_ICACHE_LINESIZE.
io: Return EBAFD for negative file descriptor on fstat (BZ #27559)
Now that fstat is implemented on top fstatat we need to handle negative
inputs. The implementation now rejects AT_FDCWD, which would otherwise
be accepted by the kernel.
Checked on x86_64-linux-gnu and on i686-linux-gnu.
DJ Delorie [Thu, 25 Feb 2021 21:08:21 +0000 (16:08 -0500)]
nscd: Fix double free in netgroupcache [BZ #27462]
In commit 745664bd798ec8fd50438605948eea594179fba1 a use-after-free
was fixed, but this led to an occasional double-free. This patch
tracks the "live" allocation better.
H.J. Lu [Tue, 2 Feb 2021 21:45:58 +0000 (13:45 -0800)]
x86: Set minimum x86-64 level marker [BZ #27318]
Since the full ISA set used in an ELF binary is unknown to compiler,
an x86-64 ISA level marker indicates the minimum, not maximum, ISA set
required to run such an ELF binary. We never guarantee a library with
an x86-64 ISA level v3 marker doesn't contain other ISAs beyond x86-64
ISA level v3, like AVX VNNI. We check the x86-64 ISA level marker for
the minimum ISA set. Since -march=sandybridge enables only some ISAs
in x86-64 ISA level v3, we should set the needed ISA marker to v2.
Otherwise, libc is compiled with -march=sandybridge will fail to run on
Sandy Bridge:
$ ./elf/ld.so ./libc.so
./libc.so: (p) CPU ISA level is lower than required: needed: 7; got: 3
Set the minimum, instead of maximum, x86-64 ISA level marker should have
no impact on the glibc-hwcaps directory assignment logic in ldconfig nor
ld.so.
DJ Delorie [Thu, 18 Feb 2021 20:26:30 +0000 (15:26 -0500)]
nss: Re-enable NSS module loading after chroot [BZ #27389]
The glibc 2.33 release enabled /etc/nsswitch.conf reloading,
and to prevent potential security issues like CVE-2019-14271
the re-loading of nsswitch.conf and all mdoules was disabled
when the root filesystem changes (see bug 27077).
Unfortunately php-lpfm and openldap both require the ability
to continue to load NSS modules after chroot. The packages
do not exec after the chroot, and so do not cause the
protections to be reset. The only solution is to re-enable
only NSS module loading (not nsswitch.conf reloading) and so
get back the previous glibc behaviour.
In the future we may introduce a way to harden applications
so they do not reload NSS modules once the root filesystem
changes, or that only files/dns are available pre-loaded
(or builtin).
tunables: Disallow negative values for some tunables
The glibc.malloc.mmap_max tunable as well as al of the INT_32 tunables
don't have use for negative values, so pin the hardcoded limits in the
non-negative range of INT. There's no real benefit in any of those
use cases for the extended range of unsigned, so I have avoided added
a new type to keep things simple.
The TUNABLE_SET interface took a primitive C type argument, which
resulted in inconsistent type conversions internally due to incorrect
dereferencing of types, especialy on 32-bit architectures. This
change simplifies the TUNABLE setting logic along with the interfaces.
Now all numeric tunable values are stored as signed numbers in
tunable_num_t, which is intmax_t. All calls to set tunables cast the
input value to its primitive type and then to tunable_num_t for
storage. This relies on gcc-specific (although I suspect other
compilers woul also do the same) unsigned to signed integer conversion
semantics, i.e. the bit pattern is conserved. The reverse conversion
is guaranteed by the standard.
nsswitch: return result when nss database is locked [BZ #27343]
Before the change nss_database_check_reload_and_get() did not populate
the '*result' value when it returned success in a case of chroot
detection. This caused initgroups() to use garage pointer in the
following test (extracted from unbound):
```
int main() {
// load some NSS modules
struct passwd * pw = getpwnam("root");
chdir("/tmp");
chroot("/tmp");
chdir("/");
// access nsswitch.conf in a chroot
initgroups("root", 0);
}
```
elf: Fix tests that rely on ld.so.cache for cross-compiling
For configurations with cross-compiling equal to 'maybe' or 'no',
ldconfig will not run and thus the ld.so.cache will not be created
on the container testroot.pristine.
This lead to failures on both tst-glibc-hwcaps-prepend-cache and
tst-ldconfig-ld_so_conf-update on environments where the same
compiler can be used to build different ABIs (powerpc and x86 for
instance).
This patch addas a new test-container hook, ldconfig.run, that
triggers a ldconfig execution prior the test execution.
x86: Use HAS_CPU_FEATURE with IBT and SHSTK [BZ #26625]
broke
GLIBC_TUNABLES=glibc.cpu.hwcaps=-IBT,-SHSTK
since it can no longer disable IBT nor SHSTK. Handle IBT and SHSTK with:
1. Revert commit 94cd37ebb293321115a36a422b091fdb72d2fb08.
2. Clears the usable CET feature bits if kernel doesn't support CET.
3. Add GLIBC_TUNABLES tests without dlopen.
4. Add tests to verify that CPU_FEATURE_USABLE on IBT and SHSTK matches
_get_ssp.
5. Update GLIBC_TUNABLES tests with dlopen to verify that CET is disabled
with GLIBC_TUNABLES.
A not so recent kernel change[1] changed how the trampoline
`__kernel_sigtramp_rt64` is used to call signal handlers.
This was exposed on the test misc/tst-sigcontext-get_pc
Before kernel 5.9, the kernel set LR to the trampoline address and
jumped directly to the signal handler, and at the end the signal
handler, as any other function, would `blr` to the address set. In
other words, the trampoline was executed just at the end of the signal
handler and the only thing it did was call sigreturn. But since
kernel 5.9 the kernel set CTRL to the signal handler and calls to the
trampoline code, the trampoline then `bctrl` to the address in CTRL,
setting the LR to the next instruction in the middle of the
trampoline, when the signal handler returns, the rest of the
trampoline code executes the same code as before.
Here is the full trampoline code as of kernel 5.11.0-rc5 for
reference:
V_FUNCTION_BEGIN(__kernel_sigtramp_rt64)
.Lsigrt_start:
bctrl /* call the handler */
addi r1, r1, __SIGNAL_FRAMESIZE
li r0,__NR_rt_sigreturn
sc
.Lsigrt_end:
V_FUNCTION_END(__kernel_sigtramp_rt64)
This new behavior breaks how `backtrace()` uses to detect the
trampoline frame to correctly reconstruct the stack frame when it is
called from inside a signal handling.
This workaround rely on the fact that the trampoline code is at very
least two (maybe 3?) instructions in size (as it is in the 32 bits
version, only on `li` and `sc`), so it is safe to check the return
address be in the range __kernel_sigtramp_rt64 .. + 4.
Before reloading nsswitch.conf, verify that the root directory
hasn't changed - if it has, it's likely that we've entered a
container and should not trust the nsswitch inside the container
nor load any shared objects therein.
Matheus Castanho [Tue, 15 Dec 2020 18:35:41 +0000 (15:35 -0300)]
elf: Limit tst-prelink-cmp target archs
elf/tst-prelink-cmp was initially added for x86 (commit fe534fe898) to validate
the fix for Bug 19178, and later applied to all architectures that use GLOB_DAT
relocations (commit 89569c8bb6). However, that bug only affected targets that
handle GLOB_DAT relocations as ELF_TYPE_CLASS_EXTERN_PROTECTED_DATA, so the test
should only apply to targets defining DL_EXTERN_PROTECTED_DATA, which gates the
usage of the elf type class above. For all other targets not meeting that
criteria, the test now returns with UNSUPPORTED status.
Fixes the test on POWER10 processors, which started using R_PPC64_GLOB_DAT.
Florian Weimer [Wed, 27 Jan 2021 12:36:12 +0000 (13:36 +0100)]
gconv: Fix assertion failure in ISO-2022-JP-3 module (bug 27256)
The conversion loop to the internal encoding does not follow
the interface contract that __GCONV_FULL_OUTPUT is only returned
after the internal wchar_t buffer has been filled completely. This
is enforced by the first of the two asserts in iconv/skeleton.c:
/* We must run out of output buffer space in this
rerun. */
assert (outbuf == outerr);
assert (nstatus == __GCONV_FULL_OUTPUT);
This commit solves this issue by queuing a second wide character
which cannot be written immediately in the state variable, like
other converters already do (e.g., BIG5-HKSCS or TSCII).
That commit turned out to be too intrusive affecting crt files, test
system and benchmark files. They should not be affected, but the
build system does not set the MODULE_NAME and LIBC_NONSHARED reliably.
Arjun Shankar [Tue, 26 Jan 2021 17:14:19 +0000 (18:14 +0100)]
benchtests: Do not build bench-timing-type with MODULE_NAME=libc
Since commit 2682695e5c7a, `make bench-build' with `--enable-static-pie'
fails due to bench-timing-type being incorrectly built with MODULE_NAME
set to `libc'. This commit sets MODULE_NAME to nonlib, thus fixing the
build failure.
Szabolcs Nagy [Fri, 22 Jan 2021 16:14:05 +0000 (16:14 +0000)]
aarch64: Move and update the definition of MTE_ENABLED
The hwcap value is now in linux 5.10 and in glibc bits/hwcap.h, so use
that definition.
Move the definition to init-arch.h so all ifunc selectors can use it
and expose an "mte" shorthand for mte enabled runtime.
For now we allow user code to enable tag checks and use PROT_MTE
mappings without libc involvment, this is not guaranteed ABI, but
can be useful for testing and debugging with MTE.
linux: mips: Fix getdents64 fallback on mips64-n32
GCC mainline shows the following error:
../sysdeps/unix/sysv/linux/mips/mips64/getdents64.c: In function '__getdents64':
../sysdeps/unix/sysv/linux/mips/mips64/getdents64.c:121:7: error: 'memcpy' forming offset [4, 7] is out of the bounds [0, 4] [-Werror=array-bounds]
121 | memcpy (((char *) dp + offsetof (struct dirent64, d_ino)),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
122 | KDP_MEMBER (kdp, d_ino), sizeof ((struct dirent64){0}.d_ino));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../sysdeps/unix/sysv/linux/mips/mips64/getdents64.c:123:7: error: 'memcpy' forming offset [4, 7] is out of the bounds [0, 4] [-Werror=array-bounds]
123 | memcpy (((char *) dp + offsetof (struct dirent64, d_off)),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
124 | KDP_MEMBER (kdp, d_off), sizeof ((struct dirent64){0}.d_off));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The issue is due both d_ino and d_off fields for mips64-n32
kernel_dirent are 32-bits, while this is using memcpy to copy 64 bits
from it into the glibc dirent64.
The fix is to use a temporary buffer to read the correct type
from kernel_dirent.
Checked with a build-many-glibcs.py for mips64el-linux-gnu and I
also checked the tst-getdents64 on mips64el 4.1.4 kernel with
and without fallback enabled (by manually setting the
getdents64_supported).
H.J. Lu [Tue, 12 Jan 2021 22:41:10 +0000 (14:41 -0800)]
x86: Check ifunc resolver with CPU_FEATURE_USABLE [BZ #27072]
Check ifunc resolver with CPU_FEATURE_USABLE and tunables in dynamic and
static executables to verify that CPUID features are initialized early in
static PIE.
Revert "linux: Move {f}xstat{at} to compat symbols" for static build
This reverts commit 20b39d59467b0c1d858e89ded8b0cebe55e22f60 for static
library. This avoids the need to rebuild the world for the case where
libstdc++ (and potentially other libraries) are linked to a old glibc.
To avoid requering to provide xstat symbols for newer ABIs (such as
riscv32) a new LIB_COMPAT macro is added. It is similar to SHLIB_COMPAT
but also works for static case (thus evaluating similar to SHLIB_COMPAT
for both shared and static case).
Checked with a check-abi on all affected ABIs. I also check if the
static library does contains the xstat symbols.
Shuo Wang [Wed, 20 Jan 2021 07:20:44 +0000 (15:20 +0800)]
aarch64: revert memcpy optimze for kunpeng to avoid performance degradation
In commit 863d775c481704baaa41855fc93e5a1ca2dc6bf6, kunpeng920 is added to default memcpy version,
however, there is performance degradation when the copy size is some large bytes, eg: 100k.
This is the result, tested in glibc-2.28:
before backport after backport Performance improvement
memcpy_1k 0.005 0.005 0.00%
memcpy_10k 0.032 0.029 10.34%
memcpy_100k 0.356 0.429 -17.02%
memcpy_1m 7.470 11.153 -33.02%
This is the demo
#include "stdio.h"
#include "string.h"
#include "stdlib.h"
char a[1024*1024] = {12};
char b[1024*1024] = {13};
int main(int argc, char *argv[])
{
int i = atoi(argv[1]);
int j;
int size = atoi(argv[2]);
for (j = 0; j < i; j++)
memcpy(b, a, size*1024);
return 0;
}
Szabolcs Nagy [Wed, 6 Jan 2021 11:31:04 +0000 (11:31 +0000)]
Make libc symbols hidden in static PIE
Hidden visibility can avoid indirections and RELATIVE relocs in
static PIE libc.
The check should use IS_IN_LIB instead of IS_IN(libc) since all
symbols are defined locally in static PIE and the optimization is
useful in all libraries not just libc. However the test system
links objects from libcrypt.a into dynamic linked test binaries
where hidden visibility does not work. I think mixing static and
shared libc components in the same binary should not be supported
usage, but to be safe only use hidden in libc.a.
On some targets (i386) this optimization cannot be applied because
hidden visibility PIE ifunc functions don't work, so it is gated by
NO_HIDDEN_EXTERN_FUNC_IN_PIE.
From -static-pie linked 'int main(){}' this shaves off 71 relative
relocs on aarch64 and reduces code size by about 2k.
Szabolcs Nagy [Tue, 19 Jan 2021 17:17:01 +0000 (17:17 +0000)]
csu: Move static pie self relocation later [BZ #27072]
IFUNC resolvers may depend on tunables and cpu feature setup so
move static pie self relocation after those.
It is hard to guarantee that the ealy startup code does not rely
on relocations so this is a bit fragile. It would be more robust
to handle RELATIVE relocs early and only IRELATIVE relocs later,
but the current relocation processing code cannot do that.
The early startup code up to relocation processing includes
On some targets IRELATIVE processing relies on TLS setup on
others TLS setup relies on IRELATIVE relocs, so the right
position for _dl_relocate_static_pie is target dependent.
For now move self relocation as early as possible on targets
that support static PIE.
Szabolcs Nagy [Fri, 15 Jan 2021 12:49:24 +0000 (12:49 +0000)]
Use hidden visibility for early static PIE code
Extern symbol access in position independent code usually involves GOT
indirection which needs RELATIVE reloc in a static linked PIE. (On
some targets this is avoided e.g. because the linker can relax a GOT
access to a pc-relative access, but this is not generally true.) Code
that runs before static PIE self relocation must avoid relying on
dynamic relocations which can be ensured by using hidden visibility.
However we cannot just make all symbols hidden:
On i386, all calls to IFUNC functions must go through PLT and calls to
hidden functions CANNOT go through PLT in PIE since EBX used in PIE PLT
may not be set up for local calls to hidden IFUNC functions.
This patch aims to make symbol references hidden in code that is used
before and by _dl_relocate_static_pie when building a static PIE libc.
Note: for an object that is used in the startup code, its references
and definition may not have consistent visibility: it is only forced
hidden in the startup code.
This is needed for fixing bug 27072.
Co-authored-by: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Szabolcs Nagy [Wed, 20 Jan 2021 12:26:31 +0000 (12:26 +0000)]
configure: Check for static PIE support
Add SUPPORT_STATIC_PIE that targets can define if they support
static PIE. This requires PI_STATIC_AND_HIDDEN support and various
linker features as described in
Szabolcs Nagy [Tue, 12 Jan 2021 16:28:27 +0000 (16:28 +0000)]
elf: Avoid RELATIVE relocs in __tunables_init
With static pie linking pointers in the tunables list need
RELATIVE relocs since the absolute address is not known at link
time. We want to avoid relocations so the static pie self
relocation can be done after tunables are initialized.
This is a simple fix that embeds the tunable strings into the
tunable list instead of using pointers. It is possible to have
a more compact representation of tunables with some additional
complexity in the generator and tunable parser logic. Such
optimization will be useful if the list of tunables grows.
There is still an issue that tunables_strdup allocates and the
failure handling code path is sufficiently complex that it can
easily have RELATIVE relocations. It is possible to avoid the
early allocation and only change environment variables in a
setuid exe after relocations are processed. But that is a
bigger change and early failure is fatal anyway so it is not
as critical to fix right away. This is bug 27181.
Szabolcs Nagy [Wed, 6 Jan 2021 17:19:24 +0000 (17:19 +0000)]
elf: Make the tunable struct definition internal only
The representation of the tunables including type information and
the tunable list structure are only used in the implementation not
in the tunables api that is exposed to usage within glibc.
This patch moves the representation related definitions into the
existing dl-tunable-types.h and uses that only for implementation.
The tunable callback and related types are moved to dl-tunables.h
because they are part of the tunables api.
This reduces the details exposed in the tunables api so the internals
are easier to change.
H.J. Lu [Fri, 25 Dec 2020 15:30:46 +0000 (07:30 -0800)]
<sys/platform/x86.h>: Remove the C preprocessor magic
In <sys/platform/x86.h>, define CPU features as enum instead of using
the C preprocessor magic to make it easier to wrap this functionality
in other languages. Move the C preprocessor magic to internal header
for better GCC codegen when more than one features are checked in a
single expression as in x86-64 dl-hwcaps-subdirs.c.
1. Rename COMMON_CPUID_INDEX_XXX to CPUID_INDEX_XXX.
2. Move CPUID_INDEX_MAX to sysdeps/x86/include/cpu-features.h.
3. Remove struct cpu_features and __x86_get_cpu_features from
<sys/platform/x86.h>.
4. Add __x86_get_cpuid_feature_leaf to <sys/platform/x86.h> and put it
in libc.
5. Make __get_cpu_features() private to glibc.
6. Replace __x86_get_cpu_features(N) with __get_cpu_features().
7. Add _dl_x86_get_cpu_features to GLIBC_PRIVATE.
8. Use a single enum index for each CPU feature detection.
9. Pass the CPUID feature leaf to __x86_get_cpuid_feature_leaf.
10. Return zero struct cpuid_feature for the older glibc binary with a
smaller CPUID_INDEX_MAX [BZ #27104].
11. Inside glibc, use the C preprocessor magic so that cpu_features data
can be loaded just once leading to more compact code for glibc.
256 bits are used for each CPUID leaf. Some leaves only contain a few
features. We can add exceptions to such leaves. But it will increase
code sizes and it is harder to provide backward/forward compatibilities
when new features are added to such leaves in the future.
When new leaves are added, _rtld_global_ro offsets will change which
leads to race condition during in-place updates. We may avoid in-place
updates by
1. Rename the old glibc.
2. Install the new glibc.
3. Remove the old glibc.
NB: A function, __x86_get_cpuid_feature_leaf , is used to avoid the copy
relocation issue with IFUNC resolver as shown in IFUNC resolver tests.
Old implementation of realpath allocates a PATH_MAX using alloca for
each symlink in the path, leading to MAXSYMLINKS times PATH_MAX
maximum stack usage.
The test create a symlink with __eloop_threshold() loops and creates
a thread with minimum stack size (obtained through
support_small_stack_thread_attribute). The thread issues a stack
allocations that fill the thread allocated stack minus some slack
plus and the realpath usage (which assumes a bounded stack usage).
If realpath uses more than about 2 * PATH_MAX plus some slack it
triggers a stackoverflow.
H.J. Lu [Fri, 15 Jan 2021 14:46:12 +0000 (06:46 -0800)]
Use <startup.h> in __libc_init_secure
Since __libc_init_secure is called before ARCH_SETUP_TLS, it must use
"int $0x80" for system calls in i386 static PIE. Add startup_getuid,
startup_geteuid, startup_getgid and startup_getegid to <startup.h>.
Update __libc_init_secure to use them.
Stafford Horne [Thu, 7 Jan 2021 21:45:36 +0000 (06:45 +0900)]
math/test-tgmath2: Fix fabs failure when no long double
I have been testing with GCC trunk and GLIBC master while working on the
OpenRISC port. This test has been failing with fabs not being called,
This is caused as my architecture is configure with no long double
meaning the two calls are the same:
TEST (fabs (Vdouble1), double, fabs);
TEST (fabs (Vldouble1), ldouble, fabs);
Instead of the tgmath calls resolving to fabs and fabsl both calls are
fabs. Next, do to compiler optimiations the second call is eliminated.
Fix this by invoking the failing TEST with Vldouble2.
Note, I also updated the FAIL message to more clearly show where the
failure happened, so I see:
FAIL: math/test-tgmath2
original exit status 1
wrong function called, fabs (ldouble) failure on line 174
H.J. Lu [Fri, 18 Sep 2020 14:55:14 +0000 (07:55 -0700)]
x86: Move x86 processor cache info to cpu_features
1. Move x86 processor cache info to _dl_x86_cpu_features in ld.so.
2. Update tunable bounds with TUNABLE_SET_WITH_BOUNDS.
3. Move x86 cache info initialization to dl-cacheinfo.h and initialize
x86 cache info in init_cpu_features ().
4. Put x86 cache info for libc in cacheinfo.h, which is included in
libc-start.c in libc.a and is included in cacheinfo.c in libc.so.
projects / thirdparty / glibc.git / log
