about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* x86_64: Undef SHADOW_STACK_POINTER_OFFSET lastH.J. Lu2018-07-152-3/+7
| | | | | | | | Since SHADOW_STACK_POINTER_OFFSET is defined in jmp_buf-ssp.h, we must undef SHADOW_STACK_POINTER_OFFSET after including <jmp_buf-ssp.h>. * sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S: Undef SHADOW_STACK_POINTER_OFFSET after including <jmp_buf-ssp.h>.
* x86: Support shadow stack pointer in setjmp/longjmpH.J. Lu2018-07-1412-1/+315
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Save and restore shadow stack pointer in setjmp and longjmp to support shadow stack in Intel CET. Use feature_1 in tcbhead_t to check if shadow stack is enabled before saving and restoring shadow stack pointer. Reviewed-by: Carlos O'Donell <carlos@redhat.com> * sysdeps/i386/__longjmp.S: Include <jmp_buf-ssp.h>. (__longjmp): Restore shadow stack pointer if shadow stack is enabled, SHADOW_STACK_POINTER_OFFSET is defined and __longjmp isn't defined for __longjmp_cancel. * sysdeps/i386/bsd-_setjmp.S: Include <jmp_buf-ssp.h>. (_setjmp): Save shadow stack pointer if shadow stack is enabled and SHADOW_STACK_POINTER_OFFSET is defined. * sysdeps/i386/bsd-setjmp.S: Include <jmp_buf-ssp.h>. (setjmp): Save shadow stack pointer if shadow stack is enabled and SHADOW_STACK_POINTER_OFFSET is defined. * sysdeps/i386/setjmp.S: Include <jmp_buf-ssp.h>. (__sigsetjmp): Save shadow stack pointer if shadow stack is enabled and SHADOW_STACK_POINTER_OFFSET is defined. * sysdeps/unix/sysv/linux/i386/____longjmp_chk.S: Include <jmp_buf-ssp.h>. (____longjmp_chk): Restore shadow stack pointer if shadow stack is enabled and SHADOW_STACK_POINTER_OFFSET is defined. * sysdeps/unix/sysv/linux/x86/Makefile (gen-as-const-headers): Remove jmp_buf-ssp.sym. * sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S: Include <jmp_buf-ssp.h>. (____longjmp_chk): Restore shadow stack pointer if shadow stack is enabled and SHADOW_STACK_POINTER_OFFSET is defined. * sysdeps/x86/Makefile (gen-as-const-headers): Add jmp_buf-ssp.sym. * sysdeps/x86/jmp_buf-ssp.sym: New dummy file. * sysdeps/x86_64/__longjmp.S: Include <jmp_buf-ssp.h>. (__longjmp): Restore shadow stack pointer if shadow stack is enabled, SHADOW_STACK_POINTER_OFFSET is defined and __longjmp isn't defined for __longjmp_cancel. * sysdeps/x86_64/setjmp.S: Include <jmp_buf-ssp.h>. (__sigsetjmp): Save shadow stack pointer if shadow stack is enabled and SHADOW_STACK_POINTER_OFFSET is defined.
* x86: Rename __glibc_reserved1 to feature_1 in tcbhead_t [BZ #22563]H.J. Lu2018-07-149-2/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | feature_1 has X86_FEATURE_1_IBT and X86_FEATURE_1_SHSTK bits for CET run-time control. CET_ENABLED, IBT_ENABLED and SHSTK_ENABLED are defined to 1 or 0 to indicate that if CET, IBT and SHSTK are enabled. <tls-setup.h> is added to set up thread-local data. Reviewed-by: Carlos O'Donell <carlos@redhat.com> [BZ #22563] * nptl/pthread_create.c: Include <tls-setup.h>. (__pthread_create_2_1): Call tls_setup_tcbhead. * sysdeps/generic/tls-setup.h: New file. * sysdeps/x86/nptl/tls-setup.h: Likewise. * sysdeps/i386/nptl/tcb-offsets.sym (FEATURE_1_OFFSET): New. * sysdeps/x86_64/nptl/tcb-offsets.sym (FEATURE_1_OFFSET): Likewise. * sysdeps/i386/nptl/tls.h (tcbhead_t): Rename __glibc_reserved1 to feature_1. * sysdeps/x86_64/nptl/tls.h (tcbhead_t): Likewise. * sysdeps/x86/sysdep.h (X86_FEATURE_1_IBT): New. (X86_FEATURE_1_SHSTK): Likewise. (CET_ENABLED): Likewise. (IBT_ENABLED): Likewise. (SHSTK_ENABLED): Likewise.
* dsb_DE locale: Fix syntax error and add tests (bug 23208).Rafal Luzynski2018-07-134-2/+85
| | | | | | | | | | | | | Fixed syntax error in the collation rules of Lower Sorbian language. Collation test added in order to test the bugs like this early. Reported-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com> [BZ #23208] * localedata/Makefile (test-input): Add dsb_DE.UTF-8. (LOCALES): Likewise. * localedata/dsb_DE.UTF-8.in: New file. * localedata/locales/dsb_DE (LC_COLLATE): Fix syntax error.
* nptl: Use __mprotect consistently for _STACK_GROWS_UPFlorian Weimer2018-07-122-1/+6
|
* Install <bits/statx.h> headerFlorian Weimer2018-07-112-1/+5
|
* Put the correct Unicode version number 11.0.0 into the generated filesMike FABIAN2018-07-105-45/+88
| | | | | | | | | | | In some places there was still the old Unicode version 10.0.0 in the files. * localedata/charmaps/UTF-8: Use correct Unicode version 11.0.0 in comment. * localedata/locales/i18n_ctype: Use correct Unicode version in comments and headers. * localedata/unicode-gen/utf8_gen.py: Add option to specify Unicode version * localedata/unicode-gen/Makefile: Use option to specify Unicode version for utf8_gen.py
* Add the statx functionFlorian Weimer2018-07-1044-1/+490
|
* Comment tst-ofdlocks-compat expected failure in some Linux releasesAdhemerval Zanella2018-07-102-0/+13
| | | | | | | | | | | | | As pointed out in a libc-alpha thread [1], the misc/tst-ofdlocks-compat may fail in some specific Linux releases. This patch adds a comment along with a link to discussion in the test source code. No changes are expected. * sysdeps/unix/sysv/linux/tst-ofdlocks-compat.c: Add a comment about a kernel issue which lead to test failure in some cases. [1] https://sourceware.org/ml/libc-alpha/2018-07/msg00243.html
* regexec: Fix off-by-one bug in weight comparison [BZ #23036]Florian Weimer2018-07-102-23/+27
| | | | | | | | | Each weight is prefixed by its length, and the length does not include itself in the count. This can be seen clearly from the find_idx function in string/strxfrm_l.c, for example. The old code behaved as if the length itself counted, thus comparing an additional byte after the weight, leading to spurious comparison failures and incorrect further partitioning of character equivalence classes.
* Fix copyright years in recent commitsFlorian Weimer2018-07-104-3/+9
|
* nss_files: Fix re-reading of long lines [BZ #18991]Florian Weimer2018-07-064-71/+339
| | | | | Use the new __libc_readline_unlocked function to pick up reading at the same line in case the buffer needs to be enlarged.
* libio: Implement internal function __libc_readline_unlockedFlorian Weimer2018-07-0610-9/+471
| | | | | | | | | | | This is a variant of fgets which fails with ERANGE if the buffer is too small, and the buffer length is given as an argument of type size_t. This function will be useful for implementing NSS file reading operations. Compared to a direct implementation using the public API, it avoids an lseek system call in case the line terminator can be found in the internal read buffer.
* aarch64: add HWCAP_ATOMICS to HWCAP_IMPORTANTSzabolcs Nagy2018-07-062-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This enables searching shared libraries in atomics/ when the hardware supports LSE atomics of armv8.1 so one can provide optimized variants of libraries in a portable way. LSE atomics does not affect library abi, the new instructions can interoperate with old ones. I considered the earlier comments on the patch https://sourceware.org/ml/libc-alpha/2018-04/msg00400.html https://sourceware.org/ml/libc-alpha/2018-04/msg00625.html It turns out that the way glibc dynamic linker decides on the search path is not very flexible: it wants to use hwcap bits and associated strings. So some targets reuse hwcap bits for glibc internal purposes to affect the search logic. But hwcap is an interface with the kernel, glibc should not allocate bits in it for its internal logic as that limits future hwcap extensions and confusing to users who expect to see hwcap bits in ifunc resolvers. Instead of rewriting the dynamic linker path logic (which affects all targets) this patch just uses the existing mechanism, however this means that the path name has to be the hwcap name "atomics" and cannot be changed to something more meaningful to users. It is hard to tell how much performance benefit this can give, in principle armv8.1 atomics can be better optimized in the hardware, so it can make a difference for synchronization heavy code. On some systems such multilib setup may be the only viable way to get optimized libraries used. * sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Add HWCAP_ATOMICS.
* aarch64: Remove HWCAP_CPUID from HWCAP_IMPORTANTSzabolcs Nagy2018-07-063-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This partially reverts commit f82e9672ad89ea1ef40bbe1af71478e255e87c5e Author: Siddhesh Poyarekar <siddhesh@sourceware.org> aarch64: Allow overriding HWCAP_CPUID feature check using HWCAP_MASK The idea was to make it possible to disable cpuid based ifunc resolution in glibc by changing the hwcap mask which the user could already control. However the hwcap mask has an orthogonal role: it specifies additional library search paths for the dynamic linker. So "cpuid" got added to the search paths when it was set in the default mask (HWCAP_IMPORTANT), which is not useful behaviour, the hwcap masking should not be reused in the cpu features code. Meanwhile there is a tunable to set the cpu explicitly so it is possible to disable the cpuid based dispatch without using a hwcap mask: GLIBC_TUNABLES=glibc.tune.cpu=generic * sysdeps/unix/sysv/linux/aarch64/cpu-features.c (init_cpu_features): Use dl_hwcap without masking. * sysdeps/unix/sysv/linux/aarch64/dl-procinfo.h (HWCAP_IMPORTANT): Remove HWCAP_CPUID.
* conform/conformtest.pl: Escape literal braces in regular expressionsFlorian Weimer2018-07-062-13/+18
| | | | | | | | | | | This suppresses Perl warnings like these: Unescaped left brace in regex is deprecated here (and will be fatal in Perl 5.32), passed through in regex; marked by <-- HERE in m/^element *({ <-- HERE ([^}]*)}|([^{ ]*)) *({([^}]*)}|([^{ ]*)) *([A-Za-z0-9_]*) *(.*)/ at conformtest.pl line 370. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Use AVX_Fast_Unaligned_Load from Zen onwards.Amit Pawar2018-07-062-5/+20
| | | | | | | From Zen onwards this will be enabled. It was disabled for the Excavator case and will remain disabled. Reviewd-by: Carlos O'Donell <carlos@redhat.com>
* Build csu/elf-init.c and csu/static-reloc.c with stack protectorFlorian Weimer2018-07-052-0/+22
| | | | | | | This does not change generated code (with -fstack-protector-strong), but is important for formal compiler flags compliance. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Compile debug/stack_chk_fail_local.c with stack protectorFlorian Weimer2018-07-052-2/+13
| | | | | The resulting object file is statically linked into applications, so it is desirable to have (formal) stack protector coverage there.
* libc-abis: Define ABSOLUTE ABI [BZ #19818][BZ #23307]Maciej W. Rozycki2018-07-054-0/+19
| | | | | | | | | | | | | | | | | | | | Define a new ABSOLUTE ABI for static linker's use with EI_ABIVERSION where correct absolute (SHN_ABS) symbol run-time load semantics is required. This way it can be ensured at static link time that a program or DSO will not suffer from previous semantics where absolute symbols were relocated by the base address, or symbols whose `st_value' is zero silently ignored leading to a confusing "undefined symbol" error message at load time, and instead "ELF file ABI version invalid" is printed with old dynamic loaders, making it clear that there is an ABI version incompatibility. [BZ #19818] [BZ #23307] * libc-abis (ABSOLUTE): New ABI. * sysdeps/unix/sysv/linux/mips/libc-abis (ABSOLUTE): New ABI. * NEWS: Mention the new ABI. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Add renameat2 function [BZ #17662]Florian Weimer2018-07-0545-5/+400
| | | | | | | The implementation falls back to renameat if renameat2 is not available in the kernel (or in the kernel headers) and the flags argument is zero. Without kernel support, a non-zero argument returns EINVAL, not ENOSYS. This mirrors what the kernel does for invalid renameat2 flags.
* posix: Fix bug-regex33 after regex syncAdhemerval Zanella2018-07-042-3/+7
| | | | | | | | | | | On some platforms the inclusion of regex-internal.h in bug-regex33 testcase show a MAX redefinition if test-skeleton.c is include later. This patch fixes by removing regex-internal.h inclusion and using SBC_MAX value directly. Checked on aarch64-linux-gnu. * posix/bug-regex33.c: Fix build after regex sync.
* locale: XFAIL newlocale usage in static binary (Bug 23164)Carlos O'Donell2018-07-048-27/+176
| | | | | | | | | | | | | | There is a glibc optimization which allows for locale categories to be removed during static compilation. There have been various bugs for this support over the years, with bug 16915 being the most recent. The solution there was to emit a reference to all the categories to avoid any being removed. This fix, although it's in the generic __nl_langinfo_l function, doesn't appear to be enough to fix the case for a statically linked program that uses newlocale and nl_langinfo_l. This commit doesn't fix the problem, but it does add a XFAIL'd test case such that a fix can be applied against this and the XFAIL removed. It's not entirely clear that the problem is the same as that which was seen in bug 16915.
* testrun.sh: Implement --tool=strace, --tool=valgrindFlorian Weimer2018-07-047-23/+65
| | | | | | | | $(file …) appears to be the only convenient way to create files with newlines and make substitution variables. This needs make 4.0 (released in 2013), so update the requirement to match. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* posix: Sync gnulib regex implementationAdhemerval Zanella2018-07-0412-1161/+1609
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch syncs the regex implementation with gnulib (commit 0ee5212). Only two changes in GLIBC regex testing are required: 1. posix/bug-regex28.c: as previously discussed [1] the change of expected results on the pattern should be safe. 2. posix/PCRE.tests: the ERE (a)|\1 is malformed (in the sense that the \1 doesn't mean anything) and although current GLIBC accepts it has undefined behavior. This patch removes the specific test. This sync contains some patches from thread 'Regex: Make libc regex more usable outside GLIBC.' [2] which have been pushed upstream in gnulib. This patches also fixes some regex issues (BZ #23233, BZ #21163, BZ #18986, BZ #13762) and I did not add testcases for both #23233 and #13762 because I couldn't think a simple way to trigger the expected failure path to trigger them. Checked on x86_64-linux-gnu and i686-linux-gnu. [BZ #23233] [BZ #21163] [BZ #18986] [BZ #13762] * posix/Makefile (tests): Add bug-regex37 and bug-regex38. * posix/PCRE.tests: Remove invalid test. * posix/bug-regex28.c: Fix expected values for used syntax. * posix/bug-regex37.c: New file. * posix/bug-regex38.c: Likewise. * posix/regcomp.c: Sync with gnulib. * posix/regex.c: Likewise. * posix/regex.h: Likewise. * posix/regex_internal.c: Likewise. * posix/regex_internal.h: Likewise. * posix/regexec.c: Likewise. [1] https://sourceware.org/ml/libc-alpha/2017-12/msg00807.html [2] https://sourceware.org/ml/libc-alpha/2017-12/msg00237.html
* Bug 23308: Update to Unicode 11.0.0Mike FABIAN2018-07-0416-2375/+4372
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unicode 11.0.0 Support: Character encoding, character type info, and transliteration tables are all updated to Unicode 11.0.0, using the generator scripts contributed by Mike FABIAN (Red Hat). Some info about the number of characters added: Total added characters in newly generated CHARMAP: 684 Total added characters in newly generated WIDTH: 119 alpha: Added 380 characters in new ctype which were not in old ctype combining: Added 56 characters in new ctype which were not in old ctype combining_level3: Added 37 characters in new ctype which were not in old ctype graph: Added 684 characters in new ctype which were not in old ctype lower: Added 82 characters in new ctype which were not in old ctype print: Added 684 characters in new ctype which were not in old ctype punct: Added 304 characters in new ctype which were not in old ctype tolower: Added 79 characters in new ctype which were not in old ctype totitle: Added 33 characters in new ctype which were not in old ctype toupper: Added 79 characters in new ctype which were not in old ctype upper: Added 79 characters in new ctype which were not in old ctype No characters were removed. [BZ #23308] * unicode-gen/Makefile (UNICODE_VERSION): Set to 11.0.0. * localedata/unicode-gen/DerivedCoreProperties.txt: Update to Unicode 11.0.0. * localedata/unicode-gen/EastAsianWidth.txt: likewise. * localedata/unicode-gen/PropList.txt: likewise. * localedata/unicode-gen/UnicodeData.txt: likewise. * localedata/charmaps/UTF-8: Regenerate. * localedata/locales/i18n_ctype: likewise. * localedata/locales/tr_TR: likewise. * localedata/locales/translit_circle: likewise. * localedata/locales/translit_cjk_compat: likewise. * localedata/locales/translit_combining: likewise. * localedata/locales/translit_compat: likewise. * localedata/locales/translit_font: likewise. * localedata/locales/translit_fraction: likewise.
* stdio-common/tst-printf.c: Remove part under a non-free license [BZ #23363]Florian Weimer2018-07-034-123/+9
| | | | | | The license does not allow modification. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* Fix hurd expected fcntl versionAdhemerval Zanella2018-07-032-1/+5
| | | | | | | | | | | Different than Linux, hurd does not need the OFD locks fix from 06ab719d30b (since OFD locks are current Linux specific). This in turn allows hurd to not provide a fcntl compat symbol. Checked on a i686-gnu with check-abi. * sysdeps/mach/hurd/i386/libc.abilist [GLIBC_2.28] (fcntl): Remove symbol.
* ldbl-128ibm-compat: Add printf_sizeGabriel F. T. Gomes2018-07-029-2/+182
| | | | | | | | | | | | | | | | | | | | | Since the addition of the _Float128 API, strfromf128 and printf_size use __printf_fp to print _Float128 values. This is achieved by setting the 'is_binary128' member of the 'printf_info' structure to one. Now that the format of long double on powerpc64le is getting a third option, this mechanism is reused for long double values that have binary128 format (i.e.: when -mabi=ieeelongdouble). This patch adds __printf_sizeieee128 as an exported symbol, but doesn't provide redirections from printf_size, yet. All redirections will be installed in a future commit, once all other functions that print or read long double values with binary128 format are ready. In __printf_fp, when 'is_binary128' is one, the floating-point argument is treated as if it was of _Float128 type, regardless of the value of 'is_long_double', thus __printf_sizeieee128 sets 'is_binary128' to the same value of 'is_long_double'. Otherwise, double values would not be printed correctly. Tested for powerpc64le.
* Use uint32_t sign in single precision math error handling functionsSzabolcs Nagy2018-07-024-11/+27
| | | | | | | | | | | | | | | | | | | | | Ideally sign should be bool, but sometimes (e.g. in powf) it's more efficient to pass a non-zero value than 1 to indicate that the sign should be set. The fixed size int is less ambigous than unsigned long. * sysdeps/ieee754/flt-32/e_powf.c (__powf): Use uint32_t. (exp2f_inline): Likewise. * sysdeps/ieee754/flt-32/math_config.h (__math_oflowf): Likewise. (__math_uflowf): Likewise. (__math_may_uflowf): Likewise. (__math_divzerof): Likewise. (__math_invalidf): Likewise. * sysdeps/ieee754/flt-32/math_errf.c (xflowf): Likewise. (__math_oflowf): Likewise. (__math_uflowf): Likewise. (__math_may_uflowf): Likewise. (__math_divzerof): Likewise. (__math_invalidf): Likewise.
* libc: Extend __libc_freeres framework (Bug 23329).Carlos O'Donell2018-06-2926-53/+245
| | | | | | | | | | | | | | | | | | | | | | | | | The __libc_freeres framework does not extend to non-libc.so objects. This causes problems in general for valgrind and mtrace detecting unfreed objects in both libdl.so and libpthread.so. This change is a pre-requisite to properly moving the malloc hooks out of malloc since such a move now requires precise accounting of all allocated data before destructors are run. This commit adds a proper hook in libc.so.6 for both libdl.so and for libpthread.so, this ensures that shm-directory.c which uses freeit () to free memory is called properly. We also remove the nptl_freeres hook and fall back to using weak-ref-and-check idiom for a loaded libpthread.so, thus making this process similar for all DSOs. Lastly we follow best practice and use explicit free calls for both libdl.so and libpthread.so instead of the generic hook process which has undefined order. Tested on x86_64 with no regressions. Signed-off-by: DJ Delorie <dj@redhat.com> Signed-off-by: Carlos O'Donell <carlos@redhat.com>
* Add long double input for strfmon testRajalakshmi Srinivasaraghavan2018-06-302-10/+32
| | | | | | | This patch adds long double type inputs in strfmon_l test which will help in long double migration. Tested for powerpc64le.
* New locale: Lower Sorbian (dsb_DE) [BZ #23208]Michael Wolf2018-06-294-0/+261
| | | | | | [BZ #23208] * localedata/SUPPORTED (dsb_DE/UTF-8): New entry. * localedata/locales/dsb_DE: New file.
* hy_AM: Add alternative month names (bug 23140).Rafal Luzynski2018-06-293-13/+32
| | | | | | | | | | | | | This locale already contained correct data in mon array. Updated from CLDR to start the month names with the lowercase letters. alt_mon is a new import from CLDR. The change has been consulted off-list with a native speaker. [BZ #23140] * localedata/locales/hy_AM (mon): Synchronize with CLDR (lowercase, genitive case). (alt_mon): New entry, import from CLDR (nominative case).
* es_BO locale: Change LC_PAPER to en_US (bug 22996).Sylvain Lesage2018-06-292-1/+6
| | | | | [BZ #22996] * localedata/locales/es_BO (LC_PAPER): Change to “copy "en_US"”.
* aarch64,falkor: Use vector registers for memcpySiddhesh Poyarekar2018-06-292-72/+68
| | | | | | | | | | | Vector registers perform better than scalar register pairs for copying data so prefer them instead. This results in a time reduction of over 50% (i.e. 2x speed improvemnet) for some smaller sizes for memcpy-walk. Larger sizes show improvements of around 1% to 2%. memcpy-random shows a very small improvement, in the range of 1-2%. * sysdeps/aarch64/multiarch/memcpy_falkor.S (__memcpy_falkor): Use vector registers.
* aarch64,falkor: Use vector registers for memmoveSiddhesh Poyarekar2018-06-292-105/+93
| | | | | | | | | | | Vector registers perform much better for moves compared to pairs of registers on falkor, so use them instead. This results in a time reduction of up to 50% (i.e. 2x improvement) for a lot of the smaller sizes, i.e. up to 1K in memmove-walk. Improvements for larger sizes are smaller, at about 1%-2%. * sysdeps/aarch64/multiarch/memmove_falkor.S (__memcpy_falkor): Use vector registers.
* Document interaction with GCC built-ins in the Customizing PrintfMartin Sebor2018-06-292-4/+17
| | | | section of the manual.
* elf: Accept absolute (SHN_ABS) symbols whose value is zero [BZ #23307]Maciej W. Rozycki2018-06-296-2/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have this condition in `check_match' (in elf/dl-lookup.c): if (__glibc_unlikely ((sym->st_value == 0 /* No value. */ && stt != STT_TLS) || ELF_MACHINE_SYM_NO_MATCH (sym) || (type_class & (sym->st_shndx == SHN_UNDEF)))) return NULL; which causes all !STT_TLS symbols whose value is zero to be silently ignored in lookup. This may make sense for regular symbols, however not for absolute (SHN_ABS) ones, where zero is like any value, there's no special meaning attached to it. Consequently legitimate programs fail, for example taking the `elf/tst-absolute-sym' test case, substituting 0 for 0x55aa in `elf/tst-absolute-sym-lib.lds' and then trying to run the resulting program we get this: $ .../elf/tst-absolute-sym .../elf/tst-absolute-sym: symbol lookup error: .../elf/tst-absolute-sym-lib.so: undefined symbol: absolute $ even though the symbol clearly is there: $ readelf --dyn-syms .../elf/tst-absolute-sym-lib.so | grep '\babsolute\b' 7: 00000000 0 NOTYPE GLOBAL DEFAULT ABS absolute $ The check for the zero value has been there since forever or commit d66e34cd4234/08162fa88891 ("Implemented runtime dynamic linker to support ELF shared libraries.") dating back to May 2nd 1995, and the problem triggers regardless of commit e7feec374c63 ("elf: Correct absolute (SHN_ABS) symbol run-time calculation [BZ #19818]") being present or not. Fix the issue then, by permitting `sym->st_value' to be 0 for SHN_ABS symbols in lookup. [BZ #23307] * elf/dl-lookup.c (check_match): Do not reject a symbol whose `st_value' is 0 if `st_shndx' is SHN_ABS. * elf/tst-absolute-zero.c: New file. * elf/tst-absolute-zero-lib.c: New file. * elf/tst-absolute-zero-lib.lds: New file. * elf/Makefile (tests): Add `tst-absolute-zero'. (modules-names): Add `tst-absolute-zero-lib'. (LDLIBS-tst-absolute-zero-lib.so): New variable. ($(objpfx)tst-absolute-zero-lib.so): New dependency. ($(objpfx)tst-absolute-zero: New dependency.
* New configure option --disable-crypt.Zack Weinberg2018-06-2912-19/+123
| | | | | | | | Some Linux distributions are experimenting with a new, separately maintained and hopefully more agile implementation of the crypt API. To facilitate this, add a configure option which disables glibc's embedded libcrypt. When this option is given, libcrypt.* and crypt.h will not be built nor installed.
* manual: Revise crypt.texi.Zack Weinberg2018-06-2918-226/+426
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a major rewrite of the description of 'crypt', 'getentropy', and 'getrandom'. A few highlights of the content changes: - Throughout the manual, public headers, and user-visible messages, I replaced the term "password" with "passphrase", the term "password database" with "user database", and the term "encrypt(ion)" with "(one-way) hashing" whenever it was applied to passphrases. I didn't bother making this change in internal code or tests. The use of the term "password" in ruserpass.c survives, because that refers to a keyword in netrc files, but it is adjusted to make this clearer. There is a note in crypt.texi explaining that they were traditionally called passwords but single words are not good enough anymore, and a note in users.texi explaining that actual passphrase hashes are found in a "shadow" database nowadays. - There is a new short introduction to the "Cryptographic Functions" section, explaining how we do not intend to be a general-purpose cryptography library, and cautioning that there _are_, or have been, legal restrictions on the use of cryptography in many countries, without getting into any kind of detail that we can't promise to keep up to date. - I added more detail about what a "one-way function" is, and why they are used to obscure passphrases for storage. I removed the paragraph saying that systems not connected to a network need no user authentication, because that's a pretty rare situation nowadays. (It still says "sometimes it is necessary" to authenticate the user, though.) - I added documentation for all of the hash functions that glibc actually supports, but not for the additional hash functions supported by libxcrypt. If we're going to keep this manual section around after the transition is more advanced, it would probably make sense to add them then. - There is much more detailed discussion of how to generate a salt, and the failure behavior for crypt is documented. (Returning an invalid hash on failure is what libxcrypt does; Solar Designer's notes say that this was done "for compatibility with old programs that assume crypt can never fail".) - As far as I can tell, the header 'crypt.h' is entirely a GNU invention, and never existed on any other Unix lineage. The function 'crypt', however, was in Issue 1 of the SVID and is now in the XSI component of POSIX. I tried to make all of the @standards annotations consistent with this, but I'm not sure I got them perfectly right. - The genpass.c example has been improved to use getentropy instead of the current time to generate the salt, and to use a SHA-256 hash instead of MD5. It uses more random bytes than is strictly necessary because I didn't want to complicate the code with proper base64 encoding. - The testpass.c example has three hardwired hashes now, to demonstrate that different one-way functions produce different hashes for the same input. It also demonstrates how DES hashing only pays attention to the first eight characters of the input. - There is new text explaining in more detail how a CSPRNG differs from a regular random number generator, and how getentropy/getrandom are not exactly a CSPRNG. I tried not to make specific falsifiable claims here. I also tried to make the blocking/cancellation/error behavior of both getentropy and getrandom clearer.
* manual: Reorganize crypt.texi.Zack Weinberg2018-06-293-119/+81
| | | | | | | | | | | | | | | | | | In preparation for a major revision of the documentation for crypt(_r), getentropy, and getrandom, reorganize crypt.texi. This patch does not change any text; it only deletes and moves text. The description of 'getpass' moves to terminal.texi, since all it does is read a password from the controlling terminal with echo disabled. The "Legal Problems" section of crypt.texi is dropped, and the introductory text is shifted down to the "Encrypting Passwords" section; the next patch will add some new introductory text. Also, it is no longer true that crypt.texi's top @node needs to have no pointers. That was a vestige of crypt/ being an add-on. (makeinfo itself doesn't need @node pointers anymore, but the scripts that assemble the libc manual's topmost node rely on each chapter-level node having them.)
* Disallow use of DES encryption functions in new programs.Zack Weinberg2018-06-2916-303/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The functions encrypt, setkey, encrypt_r, setkey_r, cbc_crypt, ecb_crypt, and des_setparity should not be used in new programs, because they use the DES block cipher, which is unacceptably weak by modern standards. Demote all of them to compatibility symbols, and remove their prototypes from installed headers. cbc_crypt, ecb_crypt, and des_setparity were already compat symbols when glibc was configured with --disable-obsolete-rpc. POSIX requires encrypt and setkey to be available when _XOPEN_CRYPT is defined, so this change also removes the definition of X_OPEN_CRYPT from <unistd.h>. The entire "DES Encryption" section is dropped from the manual, as is the mention of AUTH_DES and FIPS 140-2 in the introduction to crypt.texi. The documentation of 'memfrob' cross-referenced the DES Encryption section, which is replaced by a hyperlink to libgcrypt, and while I was in there I spruced up the actual documentation of 'memfrob' and 'strfry' a little. It's still fairly jokey, because those functions _are_ jokes, but they do also have real use cases, so people trying to use them for real should have all the information they need. DES-based authentication for Sun RPC is also insecure and should be deprecated or even removed, but maybe that can be left as TI-RPC's problem.
* malloc: Update heap dumping/undumping comments [BZ #23351]Florian Weimer2018-06-293-52/+16
| | | | | | Also remove a few now-unused declarations and definitions. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
* ast_ES: Add alternative month names (bug 23140).Rafal Luzynski2018-06-293-4/+26
| | | | | | | [BZ #23140] * localedata/locales/ast_ES (mon): Rename to... (alt_mon): This. (mon): Import from CLDR (genitive case).
* getifaddrs: Don't return ifa entries with NULL names [BZ #21812]Daniel Alvarez2018-06-292-0/+15
| | | | | | | | | | | | | | | A lookup operation in map_newlink could turn into an insert because of holes in the interface part of the map. This leads to incorrectly set the name of the interface to NULL when the interface is not present for the address being processed (most likely because the interface was added between the RTM_GETLINK and RTM_GETADDR calls to the kernel). When such changes are detected by the kernel, it'll mark the dump as "inconsistent" by setting NLM_F_DUMP_INTR flag on the next netlink message. This patch checks this condition and retries the whole operation. Hopes are that next time the interface corresponding to the address entry is present in the list and correct name is returned.
* Fix documentation build with old makeinfoSzabolcs Nagy2018-06-282-1/+5
| | | | | | With old makeinfo '@code {' fails because of the extra space. * manual/llio.texi: Remove spurious space.
* Use _STRUCT_TIMESPEC as guard in <bits/types/struct_timespec.h> [BZ #23349]Florian Weimer2018-06-282-2/+9
| | | | | | | | | | After commit d76d3703551a362b472c866b5b6089f66f8daa8e ("Fix missing timespec definition for sys/stat.h (BZ #21371)") in combination with kernel UAPI changes, GCC sanitizer builds start to fail due to a conflicting definition of struct timespec in <linux/time.h>. Use _STRUCT_TIMESPEC as the header file inclusion guard, which is already checked in the kernel header, to support including <linux/time.h> and <sys/stat.h> in the same translation unit.
* ldbl-128ibm-compat: Introduce ieee128 symbolsRajalakshmi Srinivasaraghavan2018-06-287-0/+118
| | | | | | | | | | | | | | | | This patch adds __*ieee128 symbols for strfrom, strtold, strtold_l, wcstold and wcstold_l functions. Redirection from *l to *ieee128 will be handled in separate patch once we start building these new files. 2018-06-28 Rajalakshmi Srinivasaraghavan <raji@linux.vnet.ibm.com> * sysdeps/ieee754/ldbl-128ibm-compat/Versions: Add __strfromieee128, __strtoieee128, __strtoieee128_l,__wcstoieee128 and __wcstoieee128_l. * sysdeps/ieee754/ldbl-128ibm-compat/strfromf128.c: New file. * sysdeps/ieee754/ldbl-128ibm-compat/strtof128.c: New file. * sysdeps/ieee754/ldbl-128ibm-compat/strtof128_l.c: New file. * sysdeps/ieee754/ldbl-128ibm-compat/wcstof128.c: New file. * sysdeps/ieee754/ldbl-128ibm-compat/wcstof128_l.c: New file.
* nisplus: Correct pwent parsing issue and resulting build error [BZ #23266]Maciej W. Rozycki2018-06-272-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Copy and null-terminate NIS+ password file UID and GID entries whose length is non-zero and are not terminated, in addition to empty ones, fixing a bug and a compilation issue causing an error with GCC 8: nss_nisplus/nisplus-parser.c: In function '_nss_nisplus_parse_pwent': nss_nisplus/nisplus-parser.c:90:7: error: 'strncpy' destination unchanged after copying no bytes [-Werror=stringop-truncation] strncpy (first_unused, numstr, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ nss_nisplus/nisplus-parser.c:106:7: error: 'strncpy' destination unchanged after copying no bytes [-Werror=stringop-truncation] strncpy (first_unused, numstr, len); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ introduced with commit ac05397075f6: commit ac05397075f621cfdbe1db527c96167a58b6d18e Author: Ulrich Drepper <drepper@redhat.com> Date: Sun Apr 30 07:01:26 2006 +0000 * nis/nss_nisplus/nisplus-parser.c: Minor optimizations and cleanups. Avoid copying data if it can be used in the old place. (no mailing list reference available). Obviously regardless of the recently added compiler diagnostics causing a build error this code has been long non-functional, so I guess NIS+ servers have been supplying strings that are non-empty and have already been null-terminated. Which in turn made it unnecessary to make a null-terminated copy, masking this bug. [BZ #23266] * nis/nss_nisplus/nisplus-parser.c (_nss_nisplus_parse_pwent): Copy and null-terminate entries that are not terminated, in addition to empty ones.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-09 10:09:40 +0000