aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-07-05Allow glibc to be built with _FORTIFY_SOURCEFrédéric Bérat
Add --enable-fortify-source option. It is now possible to enable fortification through a configure option. The level may be given as parameter, if none is provided, the configure script will determine what is the highest level possible that can be set considering GCC built-ins availability and set it. If level is explicitly set to 3, configure checks if the compiler supports the built-in function necessary for it or raise an error if it isn't. If the configure option isn't explicitly enabled, it _FORTIFY_SOURCE is forcibly undefined (and therefore disabled). The result of the configure checks are new variables, ${fortify_source} and ${no_fortify_source} that can be used to appropriately populate CFLAGS. A dedicated patch will follow to make use of this variable in Makefiles when necessary. Updated NEWS and INSTALL. Adding dedicated x86_64 variant that enables the configuration. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-07-03manual: Update documentation of strerror and related functionsFlorian Weimer
The current implementation of strerror is thread-safe, but this has implications for the lifetime of the return string. Describe the strerror_l function. Describe both variants of the strerror_r function. Mention the lifetime of the returned string for strerrorname_np and strerrordesc_np. Clarify that perror output depends on the current locale. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2023-07-03manual: Enhance documentation of the <ctype.h> functionsFlorian Weimer
Describe the problems with signed characters, and the glibc extension to deal with most of them. Mention that the is* functions return zero for the special argument EOF. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2023-07-03Always do locking when accessing streams (bug 15142, bug 14697)Andreas Schwab
Now that abort no longer calls fflush there is no reason to avoid locking the stdio streams anywhere. This fixes a conformance issue and potential heap corruption during exit.
2023-07-03hurd: Implement MAP_EXCLSergey Bugaev
MAP_FIXED is defined to silently replace any existing mappings at the address range being mapped over. This, however, is a dangerous, and only rarely desired behavior. Various Unix systems provide replacements or additions to MAP_FIXED: * SerenityOS and Linux provide MAP_FIXED_NOREPLACE. If the address space already contains a mapping in the requested range, Linux returns EEXIST. SerenityOS returns ENOMEM, however that is a bug, as the MAP_FIXED_NOREPLACE implementation is intended to be compatible with Linux. * FreeBSD provides the MAP_EXCL flag that has to be used in combination with MAP_FIXED. It returns EINVAL if the requested range already contains existing mappings. This is directly analogous to the O_EXCL flag in the open () call. * DragonFly BSD, NetBSD, and OpenBSD provide MAP_TRYFIXED, but with different semantics. DragonFly BSD returns ENOMEM if the requested range already contains existing mappings. NetBSD does not return an error, but instead creates the mapping at a different address if the requested range contains mappings. OpenBSD behaves the same, but also notes that this is the default behavior even without MAP_TRYFIXED (which is the case on the Hurd too). Since the Hurd leans closer to the BSD side, add MAP_EXCL as the primary API to request the behavior of not replacing existing mappings. Declare MAP_FIXED_NOREPLACE and MAP_TRYFIXED as aliases of (MAP_FIXED|MAP_EXCL), so any existing software that checks for either of those macros will pick them up automatically. For compatibility with Linux, return EEXIST if a mapping already exists. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230625231751.404120-5-bugaevc@gmail.com>
2023-07-03hurd: Fix mapping at address 0 with MAP_FIXEDSergey Bugaev
Zero address passed to mmap () typically means the caller doesn't have any specific preferred address. Not so if MAP_FIXED is passed: in this case 0 means literal 0. Fix this case to pass anywhere = 0 into vm_map. Also add some documentation. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230625231751.404120-4-bugaevc@gmail.com>
2023-07-03hurd: Fix calling vm_deallocate (NULL)Sergey Bugaev
Only call vm_deallocate when we do have the old buffer, and check for unexpected errors. Spotted while debugging a msgids/readdir issue on x86_64-gnu. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230625231751.404120-3-bugaevc@gmail.com>
2023-07-03hurd: Map brk non-executableSergey Bugaev
The rest of the heap (backed by individual pages) is already mapped RW. Mapping these pages RWX presents a security hazard. Also, in another branch memory gets allocated using vm_allocate, which sets memory protection to VM_PROT_DEFAULT (which is RW). The mismatch between protections prevents Mach from coalescing the VM map entries. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230625231751.404120-2-bugaevc@gmail.com>
2023-07-03htl: Let Mach place thread stacksSergey Bugaev
Instead of trying to allocate a thread stack at a specific address, looping over the address space, just set the ANYWHERE flag in vm_allocate (). The previous behavior: - defeats ASLR (for Mach versions that support ASLR), - is particularly slow if the lower 4 GB of the address space are mapped inaccessible, as we're planning to do on 64-bit Hurd, - is just silly. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Message-Id: <20230625231751.404120-1-bugaevc@gmail.com>
2023-07-02mach: strerror must not return NULL (bug 30555)Samuel Thibault
This follows 1d44530a5be2 ("string: strerror must not return NULL (bug 30555)"): « For strerror, this fixes commit 28aff047818eb1726394296d27b ("string: Implement strerror in terms of strerror_l"). This commit avoids returning NULL for strerror_l as well, although POSIX allows this behavior for strerror_l. »
2023-07-01hppa: xfail debug/tst-ssp-1 when have-ssp is yes (gcc-12 and later)John David Anglin
2023-07-01support: Build with exceptions and asynchronous unwind tables [BZ #30587]John David Anglin
Changing tst-cleanup4.c to use xread instead of read caused the nptl/tst-cleanupx4 test to fail. The routines in libsupport.a need to be built with exception handling and asynchronous unwind table support. v2: Use "CFLAGS-.oS" instead of "override CFLAGS".
2023-07-01hurd: Make getrandom return ENOSYS when /dev/random is not set upSamuel Thibault
So that callers (e.g. __arc4random_buf) don't try calling it again.
2023-06-30Stop applying a GCC-specific workaround on clang [BZ #30550]Tulio Magno Quites Machado Filho
GCC was the only compiler affected by the issue with __builtin_isinf_sign and float128. Fix BZ #30550. Reported-by: Qiu Chaofan <qiucofan@cn.ibm.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
2023-06-30ld.so: Always use MAP_COPY to map the first segment [BZ #30452]H.J. Lu
The first segment in a shared library may be read-only, not executable. To support LD_PREFER_MAP_32BIT_EXEC on such shared libraries, we also check MAP_DENYWRITE to decide if MAP_32BIT should be passed to mmap. Normally the first segment is mapped with MAP_COPY, which is defined as (MAP_PRIVATE | MAP_DENYWRITE). But if the segment alignment is greater than the page size, MAP_COPY isn't used to allocate enough space to ensure that the segment can be properly aligned. Map the first segment with MAP_COPY in this case to fix BZ #30452.
2023-06-30setenv.c: Get rid of alloca.Joe Simmons-Talbott
Use malloc rather than alloca to avoid potential stack overflow. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2023-06-30Add checks for wday, yday and new date formatsMartin Coufal
tm time struct contains tm_wday and tm_yday that were previously not checked in this test. Also added new test cases for date formats containing %D, %R or %h. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2023-06-30aarch64: Add vector implementations of exp routinesJoe Ramsay
Optimised implementations for single and double precision, Advanced SIMD and SVE, copied from Arm Optimized Routines. As previously, data tables are used via a barrier to prevent overly aggressive constant inlining. Special-case handlers are marked NOINLINE to avoid incurring the penalty of switching call standards unnecessarily. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
2023-06-30aarch64: Add vector implementations of log routinesJoe Ramsay
Optimised implementations for single and double precision, Advanced SIMD and SVE, copied from Arm Optimized Routines. Log lookup table added as HIDDEN symbol to allow it to be shared between AdvSIMD and SVE variants. As previously, data tables are used via a barrier to prevent overly aggressive constant inlining. Special-case handlers are marked NOINLINE to avoid incurring the penalty of switching call standards unnecessarily. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
2023-06-30aarch64: Add vector implementations of sin routinesJoe Ramsay
Optimised implementations for single and double precision, Advanced SIMD and SVE, copied from Arm Optimized Routines. As previously, data tables are used via a barrier to prevent overly aggressive constant inlining. Special-case handlers are marked NOINLINE to avoid incurring the penalty of switching call standards unnecessarily. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
2023-06-30aarch64: Add vector implementations of cos routinesJoe Ramsay
Replace the loop-over-scalar placeholder routines with optimised implementations from Arm Optimized Routines (AOR). Also add some headers containing utilities for aarch64 libmvec routines, and update libm-test-ulps. Data tables for new routines are used via a pointer with a barrier on it, in order to prevent overly aggressive constant inlining in GCC. This allows a single adrp, combined with offset loads, to be used for every constant in the table. Special-case handlers are marked NOINLINE in order to confine the save/restore overhead of switching from vector to normal calling standard. This way we only incur the extra memory access in the exceptional cases. NOINLINE definitions have been moved to math_private.h in order to reduce duplication. AOR exposes a config option, WANT_SIMD_EXCEPT, to enable selective masking (and later fixing up) of invalid lanes, in order to trigger fp exceptions correctly (AdvSIMD only). This is tested and maintained in AOR, however it is configured off at source level here for performance reasons. We keep the WANT_SIMD_EXCEPT blocks in routine sources to greatly simplify the upstreaming process from AOR to glibc. Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
2023-06-29Switch to UTF-8 for INSTALLPaul Eggert
This makes it slightly easier to read, and these days everybody can read UTF-8.
2023-06-29Make sure INSTALL is ASCII plaintextSiddhesh Poyarekar
Add --disable-encoding to makeinfo flags so that it does not generate unicode quote glyphs. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-28Update syscall lists for Linux 6.4Joseph Myers
Linux 6.4 adds the riscv_hwprobe syscall on riscv and enables memfd_secret on s390. Update syscall-names.list and regenerate the arch-syscall.h headers with build-many-glibcs.py update-syscalls. Tested with build-many-glibcs.py.
2023-06-28linux: Return unsupported if procfs can not be mount on tst-ttyname-namespaceAdhemerval Zanella
Trying to mount procfs can fail due multiples reasons: proc is locked due the container configuration, mount syscall is filtered by a Linux Secuirty Module, or any other security or hardening mechanism that Linux might eventually add. The tests does require a new procfs without binding to parent, and to fully fix it would require to change how the container was created (which is out of the scope of the test itself). Instead of trying to foresee any possible scenario, if procfs can not be mount fail with unsupported. Checked on aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-28linux: Split tst-ttynameAdhemerval Zanella
The tst-ttyname-direct.c checks the ttyname with procfs mounted in bind mode (MS_BIND|MS_REC), while tst-ttyname-namespace.c checks with procfs mount with MS_NOSUID|MS_NOEXEC|MS_NODEV in a new namespace. Checked on x86_64-linux-gnu and aarch64-linux-gnu. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-27Use Linux 6.4 in build-many-glibcs.pyJoseph Myers
This patch makes build-many-glibcs.py use Linux 6.4. Tested with build-many-glibcs.py (host-libraries, compilers and glibcs builds).
2023-06-26x86: Adjust Linux x32 dl-cache inclusion pathAdhemerval Zanella
It fixes the x32 build failure introduced by 45e2483a6c. Checked on a x86_64-linux-gnu-x32 build.
2023-06-26elf: Update list of RISC-V relocationsAndreas Schwab
2023-06-26Fix tests-clean Makefile target (bug 30545)Maxim Kuvyrkov
This patch improves tests-clean Makefile target to reliably clean test artifacts from a build directory. Before this patch tests-clean missed around 3k (out of total 9k) .out and .test-result files. Signed-off-by: Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2023-06-26check_native: Get rid of allocaJoe Simmons-Talbott
Use malloc rather than alloca to avoid potential stack overflow. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2023-06-26ifaddrs: Get rid of allocaJoe Simmons-Talbott
Use scratch_buffer and malloc rather than alloca to avoid potential stack overflows. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2023-06-26x86: Make dl-cache.h and readelflib.c not Linux-specificSergey Bugaev
These files could be useful to any port that wants to use ld.so.cache. Signed-off-by: Sergey Bugaev <bugaevc@gmail.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2023-06-26elf: Port ldconfig away from stack-allocated pathsSergey Bugaev
ldconfig was allocating PATH_MAX bytes on the stack for the library file name. The issues with PATH_MAX usage are well documented [0][1]; even if a program does not rely on paths being limited to PATH_MAX bytes, allocating 4096 bytes on the stack for paths that are typically rather short (strlen ("/lib64/libc.so.6") is 16) is wasteful and dangerous. [0]: https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html [1]: https://eklitzke.org/path-max-is-tricky Instead, make use of asprintf to dynamically allocate memory of just the right size on the heap. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Reviewed-by: Florian Weimer <fweimer@redhat.com> Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
2023-06-22Call "CST" a time zone abbreviation, not a namePaul Eggert
In documentation, call strings like "CST" time zone abbreviations, not time zone names. This terminology is more precise, and is what tzdb uses. A string like "CST" is ambiguous and does not fully name a time zone.
2023-06-22benchtests: fix warn unused resultFrederic Berat
Few tests needed to properly check for asprintf and system calls return values with _FORTIFY_SOURCE enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-22sysdeps/powerpc/fpu/tst-setcontext-fpscr.c: Fix warn unused resultFrederic Berat
The fread routine return value needs to be checked when fortification is enabled, hence use xfread helper. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-22rt/tst-mqueue4.c: Fix wrong number of argument for mq_openFrederic Berat
The mq_open routine should only get either 2 or 4 arguments, this test wrongly passed 3. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-22debug/readlink{, at}_chk.c: Harmonize declaration and definitionFrederic Berat
The declaration and definition of these routines aren't consistent. Make the definition of __readlink_chk and __readlinkat_chk match the declaration of the routines they fortify. While there are no problems today this avoids any future potential problems related to the mismatch. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-22wcsmbs/bits/wchar2{, -decl}.h: Clearly separate declaration from definitionsFrederic Berat
This will enable __REDIRECT_FORTIFY* macros to be used when _FORTIFY_SOURCE is set. Routine declarations that were in bits/wchar2.h are moved into the bits/wchar2-decl.h file. The file is now included into include/wchar.h irrespectively from fortification. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-22stdio-common: tests: Incorrect maxlen parameter for swprintfFrederic Berat
Few tests using swprintf are passing incorrect maxlen parameter. This triggers an abort when _FORTIFY_SOURCE is enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-22sysdeps/{i386, x86_64}/mempcpy_chk.S: fix linknamespace for __mempcpy_chkFrederic Berat
On i386 and x86_64, for libc.a specifically, __mempcpy_chk calls mempcpy which leads POSIX routines to call non-POSIX mempcpy indirectly. This leads the linknamespace test to fail when glibc is built with __FORTIFY_SOURCE=3. Since calling mempcpy doesn't bring any benefit for libc.a, directly call __mempcpy instead. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-20hurd: readv: Get rid of allocaJoe Simmons-Talbott
Replace alloca with a scratch_buffer to avoid potential stack overflows. Checked on i686-gnu and x86_64-linux-gnu Message-Id: <20230619144334.2902429-1-josimmon@redhat.com>
2023-06-20hurd: writev: Add back cleanup handlerJoe Simmons-Talbott
There is a potential memory leak for large writes due to writev being a "shall occur" cancellation point. Add back the cleanup handler removed in cf30aa43a5917f441c9438aaee201c53c8e1d76b. Checked on i686-gnu and x86_64-linux-gnu. Message-Id: <20230619143842.2901522-1-josimmon@redhat.com>
2023-06-19Fix misspellings -- BZ 25337Paul Pluzhnikov
2023-06-19C2x scanf %b supportJoseph Myers
ISO C2x defines scanf %b for input of binary integers (with an optional 0b or 0B prefix). Implement such support, along with the corresponding SCNb* macros in <inttypes.h>. Unlike the support for binary integers with 0b or 0B prefix with scanf %i, this is supported in all versions of scanf (independent of the standards mode used for compilation), because there are no backwards compatibility concerns (%b wasn't previously a supported format) the way there were for %i. Tested for x86_64 and x86.
2023-06-19C2x printf %wN, %wfN support (bug 24466)Joseph Myers
ISO C2x defines printf length modifiers wN (for intN_t / int_leastN_t / uintN_t / uint_leastN_t) and wfN (for int_fastN_t / uint_fastN_t). Add support for those length modifiers (such a feature was previously requested in bug 24466). scanf support is to be added separately. GCC 13 has format checking support for these modifiers. When used with the support for registering format specifiers, these modifiers are translated to existing flags in struct printf_info, rather than trying to add some way of distinguishing them without breaking the printf_info ABI. C2x requires an error to be returned for unsupported values of N; this is implemented for printf-family functions, but the parse_printf_format interface doesn't support error returns, so such an error gets discarded by that function. Tested for x86_64 and x86.
2023-06-19tests: replace system by xsystemFrédéric Bérat
With fortification enabled, system calls return result needs to be checked, has it gets the __wur macro enabled. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-19tests: replace read by xreadFrédéric Bérat
With fortification enabled, read calls return result needs to be checked, has it gets the __wur macro enabled. Note on read call removal from sysdeps/pthread/tst-cancel20.c and sysdeps/pthread/tst-cancel21.c: It is assumed that this second read call was there to overcome the race condition between pipe closure and thread cancellation that could happen in the original code. Since this race condition got fixed by d0e3ffb7a58854248f1d5e737610d50cd0a60f46 the second call seems superfluous. Hence, instead of checking for the return value of read, it looks reasonable to simply remove it. Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-19hurd: writev: Get rid of allocaJoe Simmons-Talbott
Use a scratch_buffer rather than alloca to avoid potential stack overflows. Checked on i686-gnu and x86_64-linux-gnu Message-Id: <20230608155844.976554-1-josimmon@redhat.com>