about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* rtld: Avoid using up static TLS surplus for optimizations [BZ #25051]Szabolcs Nagy2020-07-0818-17/+382
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On some targets static TLS surplus area can be used opportunistically for dynamically loaded modules such that the TLS access then becomes faster (TLSDESC and powerpc TLS optimization). However we don't want all surplus TLS to be used for this optimization because dynamically loaded modules with initial-exec model TLS can only use surplus TLS. The new contract for surplus static TLS use is: - libc.so can have up to 192 bytes of IE TLS, - other system libraries together can have up to 144 bytes of IE TLS. - Some "optional" static TLS is available for opportunistic use. The optional TLS is now tunable: rtld.optional_static_tls, so users can directly affect the allocated static TLS size. (Note that module unloading with dlclose does not reclaim static TLS. After the optional TLS runs out, TLS access is no longer optimized to use static TLS.) The default setting of rtld.optional_static_tls is 512 so the surplus TLS is 3*192 + 4*144 + 512 = 1664 by default, the same as before. Fixes BZ #25051. Tested on aarch64-linux-gnu and x86_64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* rtld: Account static TLS surplus for audit modulesSzabolcs Nagy2020-07-085-13/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | The new static TLS surplus size computation is surplus_tls = 192 * (nns-1) + 144 * nns + 512 where nns is controlled via the rtld.nns tunable. This commit accounts audit modules too so nns = rtld.nns + audit modules. rtld.nns should only include the namespaces required by the application, namespaces for audit modules are accounted on top of that so audit modules don't use up the static TLS that is reserved for the application. This allows loading many audit modules without tuning rtld.nns or using up static TLS, and it fixes FAIL: elf/tst-auditmany Note that DL_NNS is currently a hard upper limit for nns, and if rtld.nns + audit modules go over the limit that's a fatal error. By default rtld.nns is 4 which allows 12 audit modules. Counting the audit modules is based on existing audit string parsing code, we cannot use GLRO(dl_naudit) before the modules are actually loaded.
* rtld: Add rtld.nns tunable for the number of supported namespacesSzabolcs Nagy2020-07-086-19/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TLS_STATIC_SURPLUS is 1664 bytes currently which is not enough to support DL_NNS (== 16) number of dynamic link namespaces, if we assume 192 bytes of TLS are reserved for libc use and 144 bytes are reserved for other system libraries that use IE TLS. A new tunable is introduced to control the number of supported namespaces and to adjust the surplus static TLS size as follows: surplus_tls = 192 * (rtld.nns-1) + 144 * rtld.nns + 512 The default is rtld.nns == 4 and then the surplus TLS size is the same as before, so the behaviour is unchanged by default. If an application creates more namespaces than the rtld.nns setting allows, then it is not guaranteed to work, but the limit is not checked. So existing usage will continue to work, but in the future if an application creates more than 4 dynamic link namespaces then the tunable will need to be set. In this patch DL_NNS is a fixed value and provides a maximum to the rtld.nns setting. Static linking used fixed 2048 bytes surplus TLS, this is changed so the same contract is used as for dynamic linking. With static linking DL_NNS == 1 so rtld.nns tunable is forced to 1, so by default the surplus TLS is reduced to 144 + 512 = 656 bytes. This change is not expected to cause problems. Tested on aarch64-linux-gnu and x86_64-linux-gnu. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Remove --enable-obsolete-nsl configure flagPetr Vorel2020-07-0871-11162/+48
| | | | | | | | | | | | | | | | | | | this means that *always* libnsl is only built as shared library for backward compatibility and the NSS modules libnss_nis and libnss_nisplus are not built at all, libnsl's headers aren't installed. This compatibility is kept only for architectures and ABIs that have been added in or before version 2.28. Replacement implementations based on TIRPC, which additionally support IPv6, are available from <https://github.com/thkukuk/>. This change does not affect libnss_compat which does not depended on libnsl since 2.27 and thus can be used without NIS. libnsl code depends on Sun RPC, e.g. on --enable-obsolete-rpc (installed libnsl headers use installed Sun RPC headers), which will be removed in the following commit.
* Move non-deprecated RPC-related functions from sunrpc to inetFlorian Weimer2020-07-0810-10/+10
| | | | | | This includes bindresvport and the NSS-related RPC functions. This will simplify the removal of the sunrpc functionality because these functions no longer have to be treated specially.
* aarch64: add NEWS entry about branch protection supportSzabolcs Nagy2020-07-081-0/+11
| | | | | | This is a new security feature that relies on architecture extensions and needs glibc to be built with a gcc configured with branch protection.
* aarch64: redefine RETURN_ADDRESS to strip PACSzabolcs Nagy2020-07-081-0/+7
| | | | | | | | | | | | | | RETURN_ADDRESS is used at several places in glibc to mean a valid code address of the call site, but with pac-ret it may contain a pointer authentication code (PAC), so its definition is adjusted. This is gcc PR target/94891: __builtin_return_address should not expose signed pointers to user code where it can cause ABI issues. In glibc RETURN_ADDRESS is only changed if it is built with pac-ret. There is no detection for the specific gcc issue because it is hard to test and the additional xpac does not cause problems. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: fix pac-ret support in _mcountSzabolcs Nagy2020-07-082-1/+13
| | | | | | | | | | | | | | | | | | | Currently gcc -pg -mbranch-protection=pac-ret passes signed return address to _mcount, so _mcount now has to always strip pac from the frompc since that's from user code that may be built with pac-ret. This is gcc PR target/94791: signed pointers should not escape and get passed across extern call boundaries, since that's an ABI break, but because existing gcc has this issue we work it around in glibc until that is resolved. This is compatible with a fixed gcc and it is a nop on systems without PAuth support. The bug was introduced in gcc-7 with -msign-return-address=non-leaf|all support which in gcc-9 got renamed to -mbranch-protection=pac-ret|pac-ret+leaf|standard. strip_pac uses inline asm instead of __builtin_aarch64_xpaclri since that is not a documented api and not available in all supported gccs. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: Add pac-ret support to assembly filesSzabolcs Nagy2020-07-085-1/+47
| | | | | | | | | | | | Use return address signing in assembly files for functions that save LR when pac-ret is enabled in the compiler. The GNU property note for PAC-RET is not meaningful to the dynamic linker so it is not strictly required, but it may be used to track the security property of binaries. (The PAC-RET property is only set if BTI is set too because BTI implies working GNU property support.) Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: configure check for pac-ret code generationSzabolcs Nagy2020-07-083-0/+63
| | | | | | | | | | | | | Return address signing requires unwinder support, which is present in libgcc since >=gcc-7, however due to bugs the support may be broken in <gcc-10 (and similarly there may be issues in custom unwinders), so pac-ret is not always safe to use. So in assembly code glibc should only use pac-ret if the compiler uses it too. Unfortunately there is no predefined feature macro for it set by the compiler so pac-ret is inferred from the code generation. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: ensure objects are BTI compatibleSzabolcs Nagy2020-07-083-0/+11
| | | | | | | | | | | | | | | | | | | When glibc is built with branch protection (i.e. with a gcc configured with --enable-standard-branch-protection), all glibc binaries should be BTI compatible and marked as such. It is easy to link BTI incompatible objects by accident and this is silent currently which is usually not the expectation, so this is changed into a link error. (There is no linker flag for failing on BTI incompatible inputs so all warnings are turned into fatal errors outside the test system when building glibc with branch protection.) Unfortunately, outlined atomic functions are not BTI compatible in libgcc (PR libgcc/96001), so to build glibc with current gcc use 'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon and then glibc can be built and tested without such workarounds. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: enable BTI at runtimeSudakshina Das2020-07-088-0/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Binaries can opt-in to using BTI via an ELF object file marking. The dynamic linker has to then mprotect the executable segments with PROT_BTI. In case of static linked executables or in case of the dynamic linker itself, PROT_BTI protection is done by the operating system. On AArch64 glibc uses PT_GNU_PROPERTY instead of PT_NOTE to check the properties of a binary because PT_NOTE can be unreliable with old linkers (old linkers just append the notes of input objects together and add them to the output without checking them for consistency which means multiple incompatible GNU property notes can be present in PT_NOTE). BTI property is handled in the loader even if glibc is not built with BTI support, so in theory user code can be BTI protected independently of glibc. In practice though user binaries are not marked with the BTI property if glibc has no support because the static linked libc objects (crt files, libc_nonshared.a) are unmarked. This patch relies on Linux userspace API that is not yet in a linux release but in v5.8-rc1 so scheduled to be in Linux 5.8. Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: fix RTLD_START for BTISzabolcs Nagy2020-07-081-1/+4
| | | | | | | | | | | | | Tailcalls must use x16 or x17 for the indirect branch instruction to be compatible with code that uses BTI c at function entries. (Other forms of indirect branches can only land on BTI j.) Also added a BTI c at the ELF entry point of rtld, this is not strictly necessary since the kernel does not use indirect branch to get there, but it seems safest once building glibc itself with BTI is supported. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: fix swapcontext for BTISzabolcs Nagy2020-07-081-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | setcontext returns to the specified context via an indirect jump, so there should be a BTI j. In case of getcontext (and all other returns_twice functions) the compiler adds BTI j at the call site, but swapcontext is a normal c call that is currently not handled specially by the compiler. So we change swapcontext such that the saved context returns to a local address that has BTI j and then swapcontext returns to the caller via a normal RET. For this we save the original return address in the slot for x1 of the context because x1 need not be preserved by swapcontext but it is restored when the context saved by swapcontext is resumed. The alternative fix (which is done on x86) would make swapcontext special in the compiler so BTI j is emitted at call sites, on x86 there is an indirect_return attribute for this, on AArch64 we would have to use returns_twice. It was decided against because such fix may need user code updates: the attribute has to be added when swapcontext is called via a function pointer and it breaks always_inline functions with swapcontext. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: Add BTI support to assembly filesSudakshina Das2020-07-0810-1/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | To enable building glibc with branch protection, assembly code needs BTI landing pads and ELF object file markings in the form of a GNU property note. The landing pads are unconditionally added to all functions that may be indirectly called. When the code segment is not mapped with PROT_BTI these instructions are nops. They are kept in the code when BTI is not supported so that the layout of performance critical code is unchanged across configurations. The GNU property notes are only added when there is support for BTI in the toolchain, because old binutils does not handle the notes right. (Does not know how to merge them nor to put them in PT_GNU_PROPERTY segment instead of PT_NOTE, and some versions of binutils emit warnings about the unknown GNU property. In such cases the produced libc binaries would not have valid ELF marking so BTI would not be enabled.) Note: functions using ENTRY or ENTRY_ALIGN now start with an additional BTI c, so alignment of the following code changes, but ENTRY_ALIGN_AND_PAD was fixed so there is no change to the existing code layout. Some string functions may need to be tuned for optimal performance after this commit. Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: Rename place holder .S files to .cSzabolcs Nagy2020-07-083-0/+0
| | | | | | | | The compiler can add required elf markings based on CFLAGS but the assembler cannot, so using C code for empty files creates less of a maintenance problem. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: configure test for BTI supportSzabolcs Nagy2020-07-083-0/+64
| | | | | | | | | | | | | Check BTI support in the compiler and linker. The check also requires READELF that understands the BTI GNU property note. It is expected to succeed with gcc >=gcc-9 configured with --enable-standard-branch-protection and binutils >=binutils-2.33. Note: passing -mbranch-protection=bti in CFLAGS when building glibc may not be enough to get a glibc that supports BTI because crtbegin* and crtend* provided by the compiler needs to be BTI compatible too. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Rewrite abi-note.S in C.Szabolcs Nagy2020-07-082-18/+15
| | | | | | | | Using C code allows the compiler to add target specific object file markings based on CFLAGS. The arm specific abi-note.S is removed and similar object file fix up will be avoided on AArch64 with standard branch protection.
* rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handlingSzabolcs Nagy2020-07-085-64/+118
| | | | | | | | | | | | | | | | | | | | | | Add generic code to handle PT_GNU_PROPERTY notes. Invalid content is ignored, _dl_process_pt_gnu_property is always called after PT_LOAD segments are mapped and it has no failure modes. Currently only one NT_GNU_PROPERTY_TYPE_0 note is handled, which contains target specific properties: the _dl_process_gnu_property hook is called for each property. The old _dl_process_pt_note and _rtld_process_pt_note differ in how the program header is read. The old _dl_process_pt_note is called before PT_LOAD segments are mapped and _rtld_process_pt_note is called after PT_LOAD segments are mapped. The old _rtld_process_pt_note is removed and _dl_process_pt_note is always called after PT_LOAD segments are mapped and now it has no failure modes. The program headers are scanned backwards so that PT_NOTE can be skipped if PT_GNU_PROPERTY exists. Co-Authored-By: H.J. Lu <hjl.tools@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* string: Move tst-strsignal tst-strerror to tests-containerAdhemerval Zanella2020-07-081-1/+3
| | | | | | | Both tests require libc.mo translation files which might not be installed on the system. Checked on x86_64-linux-gnu.
* string: Fix prototype mismatch in sigabbrev_np, __sigdescr_npFlorian Weimer2020-07-082-2/+2
| | | | GCC 6 does not ignore the const specifier on the return type.
* arm: CVE-2020-6096: Fix multiarch memcpy for negative length [BZ #25620]Alexander Anisimov2020-07-081-11/+11
| | | | | | Unsigned branch instructions could be used for r2 to fix the wrong behavior when a negative length is passed to memcpy. This commit fixes the armv7 version.
* arm: CVE-2020-6096: fix memcpy and memmove for negative length [BZ #25620]Evgeny Eremin2020-07-082-28/+20
| | | | | | Unsigned branch instructions could be used for r2 to fix the wrong behavior when a negative length is passed to memcpy and memmove. This commit fixes the generic arm implementation of memcpy amd memmove.
* sunrpc: Remove hidden aliases for global data symbols (bug 26210)Florian Weimer2020-07-083-9/+8
| | | | | | | | | | | | | It is generally not possible to add hidden aliases for global data symbols: If the main executable contains a copy relocation against the symbol, the hidden aliases keep pointing to the glibc-internal copy of the symbol, instead of the symbol actually used by the application. Fixes commit 89aacb513eb77549a29df2638913a0f8178cf3f5 ("sunrpc: Remove stray exports without --enable-obsolete-rpc [BZ #23166]"). Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* hurd: Fix strerror not setting errnoSamuel Thibault2020-07-071-5/+11
| | | | | * sysdeps/mach/strerror_l.c: Include <errno.h>. (__strerror_l): Save errno on entry and restore it on exit.
* tst-strsignal: fix checking for RT signals supportSamuel Thibault2020-07-071-4/+8
| | | | | | * string/tst-strsignal.c (do_test): Actually check that RT signals are available by comparing SIGRTMAX to SIGRTMIN. Check that SIGRTMAX is 64 before testing for a message reporting 65 for SIGRTMAX+1.
* hurd: Evaluate fd before entering the critical sectionSamuel Thibault2020-07-071-1/+2
| | | | | * sysdeps/hurd/include/hurd/fd.h (HURD_FD_PORT_USE_CANCEL): Evaluate fd before calling _hurd_critical_section_lock.
* Rewrite iconv option parsing [BZ #19519]Arjun Shankar2020-07-0711-143/+988
| | | | | | | | | | | | | | | | This commit replaces string manipulation during `iconv_open' and iconv_prog option parsing with a structured, flag based conversion specification. In doing so, it alters the internal `__gconv_open' interface and accordingly adjusts its uses. This change fixes several hangs in the iconv program and therefore includes a new test to exercise iconv_prog options that originally led to these hangs. It also includes a new regression test for option handling in the iconv function. Reviewed-by: Florian Weimer <fweimer@redhat.com> Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* nss: Remove cryptographic key support from nss_files, nss_nis, nss_nisplusFlorian Weimer2020-07-076-760/+9
| | | | | | | | The interface has hard-coded buffer sizes and is therefore tied to DES. It also does not match current practice where different services on the same host use different key material. This change simplifies removal of the sunrpc code.
* sunrpc: Do not export getrpcport by defaultFlorian Weimer2020-07-071-0/+5
| | | | | | This function looks like an NSS function, but is actually a wrapper around pmap_getport, so it should only be exported with --enable-obsolete-rpc.
* sunrpc: Do not export key handling hooks by defaultFlorian Weimer2020-07-071-3/+14
| | | | | | __key_encryptsession_pk_LOCAL, __key_decryptsession_pk_LOCAL, __key_gendes_LOCAL had a default version symbol even without --enable-obsolete-rpc.
* sunrpc: Turn clnt_sperrno into a libc_hidden_nolink_sunrpc symbolFlorian Weimer2020-07-071-0/+4
| | | | | Before this change, the function had a default symbol version even without --enable-obsolete-rpc.
* string: Add strerrorname_np and strerrordesc_npAdhemerval Zanella2020-07-0742-1/+259
| | | | | | | | | | | | | | | | | The strerrorname_np returns error number name (e.g. "EINVAL" for EINVAL) while strerrordesc_np returns string describing error number (e.g "Invalid argument" for EINVAL). Different than strerror, strerrordesc_np does not attempt to translate the return description, both functions return NULL for an invalid error number. They should be used instead of sys_errlist and sys_nerr, both are thread and async-signal safe. These functions are GNU extensions. Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* string: Add sigabbrev_np and sigdescr_npAdhemerval Zanella2020-07-0743-10/+236
| | | | | | | | | | | | | | | | | | The sigabbrev_np returns the abbreviated signal name (e.g. "HUP" for SIGHUP) while sigdescr_np returns the string describing the error number (e.g "Hangup" for SIGHUP). Different than strsignal, sigdescr_np does not attempt to translate the return description and both functions return NULL for an invalid signal number. They should be used instead of sys_siglist or sys_sigabbrev and they are both thread and async-signal safe. They are added as GNU extensions on string.h header (same as strsignal). Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* string: Add strerror_l on test-strerror-errnoAdhemerval Zanella2020-07-071-0/+5
| | | | | | | | Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* string: Add strerror, strerror_r, and strerror_l testAdhemerval Zanella2020-07-076-1/+145
| | | | | | | | Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* string: Add strsignal testAdhemerval Zanella2020-07-072-2/+61
| | | | | | | | Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* string: Simplify strerror_rAdhemerval Zanella2020-07-072-101/+7
| | | | | | | | | | | | Use snprintf instead of mempcpy plus itoa_word and remove unused definitions. There is no potential for infinite recursion because snprintf only use strerror_r for the %m specifier. Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* string: Use tls-internal on strerror_lAdhemerval Zanella2020-07-077-40/+20
| | | | | | | | | | The buffer allocation uses the same strategy of strsignal. Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* string: Implement strerror in terms of strerror_lAdhemerval Zanella2020-07-075-26/+24
| | | | | | | | | | | | | | If the thread is terminated then __libc_thread_freeres will free the storage via __glibc_tls_internal_free. It is only within the calling thread that this matters. It makes strerror MT-safe. Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* string: Remove old TLS usage on strsignalAdhemerval Zanella2020-07-0710-91/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The per-thread state is refactored two use two strategies: 1. The default one uses a TLS structure, which will be placed in the static TLS space (using __thread keyword). 2. Linux allocates via struct pthread and access it through THREAD_* macros. The default strategy has the disadvantage of increasing libc.so static TLS consumption and thus decreasing the possible surplus used in some scenarios (which might be mitigated by BZ#25051 fix). It is used only on Hurd, where accessing the thread storage in the in single thread case is not straightforward (afaiu, Hurd developers could correct me here). The fallback static allocation used for allocation failure is also removed: defining its size is problematic without synchronizing with translated messages (to avoid partial translation) and the resulting usage is not thread-safe. Checked on x86-64-linux-gnu, i686-linux-gnu, powerpc64le-linux-gnu, and s390x-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* linux: Fix __NSIG_WORDS and add __NSIG_BYTESAdhemerval Zanella2020-07-0715-28/+43
| | | | | | | | | | | | | | The __NSIG_WORDS value is based on minimum number of words to hold the maximum number of signals supported by the architecture. This patch also adds __NSIG_BYTES, which is the number of bytes required to represent the supported number of signals. It is used in syscalls which takes a sigset_t. Checked on x86_64-linux-gnu and i686-linux-gnu. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* signal: Move sys_errlist to a compat symbolAdhemerval Zanella2020-07-0730-1898/+1115
| | | | | | | | | | | | | | | | | | | | The symbol is deprecated by strerror since its usage imposes some issues such as copy relocations. Its internal name is also changed to _sys_errlist_internal to avoid static linking usage. The compat code is also refactored by removing the over enginered errlist-compat.c generation from manual entried and extra comment token in linker script file. It disantangle the code generation from manual and simplify both Linux and Hurd compat code. The definitions from errlist.c are moved to errlist.h and a new test is added to avoid a new errno entry without an associated one in manual. Checked on x86_64-linux-gnu and i686-linux-gnu. I also run a check-abi on all affected platforms. Tested-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* signal: Move sys_siglist to a compat symbolAdhemerval Zanella2020-07-0714-116/+93
| | | | | | | | | | | | | | | | | | | The symbol was deprecated by strsignal and its usage imposes issues such as copy relocations. Its internal name is changed to __sys_siglist and __sys_sigabbrev to avoid static linking usage. The compat code is also refactored, since both Linux and Hurd usage the same strategy: export the same array with different object sizes. The libSegfault change avoids calling strsignal on the SIGFAULT signal handler (the current usage is already sketchy, adding a call that potentially issue locale internal function is even sketchier). Checked on x86_64-linux-gnu and i686-linux-gnu. I also run a check-abi on all affected platforms. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* signal: Add signum-{generic,arch}.hAdhemerval Zanella2020-07-0718-374/+461
| | | | | | | | | | | | | | | | | | | | It refactor how signals are defined by each architecture. Instead of include a generic header (bits/signum-generic.h) and undef non-default values in an arch specific header (bits/signum.h) the new scheme uses a common definition (bits/signum-generic.h) and each architectures add its specific definitions on a new header (bits/signum-arch.h). For Linux it requires copy some system default definitions to alpha, hppa, and sparc. They are historical values and newer ports uses the generic Linux signum-arch.h. For Hurd the BSD signum is removed and moved to a new header (it is used currently only on Hurd). Checked on a build against all affected ABIs. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>
* Remove most vfprintf width/precision-dependent allocations (bug 14231, bug ↵Joseph Myers2020-07-074-121/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 26211). The vfprintf implementation (used for all printf-family functions) contains complicated logic to allocate internal buffers of a size depending on the width and precision used for a format, using either malloc or alloca depending on that size, and with consequent checks for size overflow and allocation failure. As noted in bug 26211, the version of that logic used when '$' plus argument number formats are in use is missing the overflow checks, which can result in segfaults (quite possibly exploitable, I didn't try to work that out) when the width or precision is in the range 0x7fffffe0 through 0x7fffffff (maybe smaller values as well in the wprintf case on 32-bit systems, when the multiplication by sizeof (CHAR_T) can overflow). All that complicated logic in fact appears to be useless. As far as I can tell, there has been no need (outside the floating-point printf code, which does its own allocations) for allocations depending on width or precision since commit 3e95f6602b226e0de06aaff686dc47b282d7cc16 ("Remove limitation on size of precision for integers", Sun Sep 12 21:23:32 1999 +0000). Thus, this patch removes that logic completely, thereby fixing both problems with excessive allocations for large width and precision for non-floating-point formats, and the problem with missing overflow checks with such allocations. Note that this does have the consequence that width and precision up to INT_MAX are now allowed where previously INT_MAX / sizeof (CHAR_T) - EXTSIZ or more would have been rejected, so could potentially expose any other overflows where the value would previously have been rejected by those removed checks. I believe this completely fixes bugs 14231 and 26211. Excessive allocations are still possible in the floating-point case (bug 21127), as are other integer or buffer overflows (see bug 26201). This does not address the cases where a precision larger than INT_MAX (embedded in the format string) would be meaningful without printf's return value overflowing (when it's used with a string format, or %g without the '#' flag, so the actual output will be much smaller), as mentioned in bug 17829 comment 8; using size_t internally for precision to handle that case would be complicated by struct printf_info being a public ABI. Nor does it address the matter of an INT_MIN width being negated (bug 17829 comment 7; the same logic appears a second time in the file as well, in the form of multiplying by -1). There may be other sources of memory allocations with malloc in printf functions as well (bug 24988, bug 16060). From inspection, I think there are also integer overflows in two copies of "if ((width -= len) < 0)" logic (where width is int, len is size_t and a very long string could result in spurious padding being output on a 32-bit system before printf overflows the count of output characters). Tested for x86-64 and x86.
* elf: Do not signal LA_ACT_CONSISTENT for an empty namespace [BZ #26076]Florian Weimer2020-07-071-2/+8
| | | | | | | | | The auditing interface identifies namespaces by their first loaded module. Once the namespace is empty, it is no longer possible to signal LA_ACT_CONSISTENT for it because the first loaded module is already gone at that point. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Fix stringop-overflow errors from gcc 10 in iconv.Stefan Liebler2020-07-072-9/+13
| | | | | | | On s390x, I've recognize various -Werror=stringop-overflow messages in iconv/loop.c and iconv/skeleton.c if build with gcc10 -O3. With this commit gcc knows the size and do not raise those errors anymore.
* x86: Add thresholds for "rep movsb/stosb" to tunablesH.J. Lu2020-07-067-26/+86
| | | | | | | | | | Add x86_rep_movsb_threshold and x86_rep_stosb_threshold to tunables to update thresholds for "rep movsb" and "rep stosb" at run-time. Note that the user specified threshold for "rep movsb" smaller than the minimum threshold will be ignored. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Use C2x return value from getpayload of non-NaN (bug 26073).Joseph Myers2020-07-068-14/+33
| | | | | | | | | | | | | | | In TS 18661-1, getpayload had an unspecified return value for a non-NaN argument, while C2x requires the return value -1 in that case. This patch implements the return value of -1. I don't think this is worth having a new symbol version that's an alias of the old one, although occasionally we do that in such cases where the new function semantics are a refinement of the old ones (to avoid programs relying on the new semantics running on older glibc versions but not behaving as intended). Tested for x86_64 and x86; also ran math/ tests for aarch64 and powerpc.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-07-07 01:18:07 +0000