glibc/misc/sys, branch master

socket: Use may_alias on sockaddr structs (bug 19622)

2024-05-18T07:33:19Z

This supports common coding patterns. The GCC C front end before version 7 rejects the may_alias attribute on a struct definition if it was not present in a previous forward declaration, so this attribute can only be conditionally applied. This implements the spirit of the change in Austin Group issue 1641. Suggested-by: Marek Polacek Suggested-by: Jakub Jelinek Reviewed-by: Sam James Reviewed-by: Carlos O'Donell

Always define __USE_TIME_BITS64 when 64 bit time_t is used

2024-04-02T18:28:36Z

It was raised on libc-help [1] that some Linux kernel interfaces expect the libc to define __USE_TIME_BITS64 to indicate the time_t size for the kABI. Different than defined by the initial y2038 design document [2], the __USE_TIME_BITS64 is only defined for ABIs that support more than one time_t size (by defining the _TIME_BITS for each module). The 64 bit time_t redirects are now enabled using a different internal define (__USE_TIME64_REDIRECTS). There is no expected change in semantic or code generation. Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and arm-linux-gnueabi [1] https://sourceware.org/pipermail/libc-help/2024-January/006557.html [2] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign Reviewed-by: DJ Delorie

cdefs: Drop access attribute for _FORTIFY_SOURCE=3 (BZ #31383)

2024-02-28T13:35:10Z

When passed a pointer to a zero-sized struct, the access attribute without the third argument misleads -Wstringop-overflow diagnostics to think that a function is writing 1 byte into the zero-sized structs. The attribute doesn't add that much value in this context, so drop it completely for _FORTIFY_SOURCE=3. Resolves: BZ #31383 Signed-off-by: Siddhesh Poyarekar Reviewed-by: Adhemerval Zanella

debug: Improve fcntl.h fortify warnings with clang

2024-02-27T13:52:59Z

It improves open, open64, openat, and openat64. The compile and runtime checks have similar coverage as with GCC. Checked on aarch64, armhf, x86_64, and i686. Reviewed-by: Carlos O'Donell Tested-by: Carlos O'Donell

cdefs.h: Add clang fortify directives

2024-02-27T13:52:57Z

For instance, the read wrapper is currently expanded as: extern __inline __attribute__((__always_inline__)) __attribute__((__artificial__)) __attribute__((__warn_unused_result__)) ssize_t read (int __fd, void *__buf, size_t __nbytes) { return __glibc_safe_or_unknown_len (__nbytes, sizeof (char), __glibc_objsize0 (__buf)) ? __read_alias (__fd, __buf, __nbytes) : __glibc_unsafe_len (__nbytes, sizeof (char), __glibc_objsize0 (__buf)) ? __read_chk_warn (__fd, __buf, __nbytes, __builtin_object_size (__buf, 0)) : __read_chk (__fd, __buf, __nbytes, __builtin_object_size (__buf, 0)); } The wrapper relies on __builtin_object_size call lowers to a constant at compile-time and many other operations in the wrapper depends on having a single, known value for parameters. Because this is impossible to have for function parameters, the wrapper depends heavily on inlining to work and While this is an entirely viable approach on GCC, it is not fully reliable on clang. This is because by the time llvm gets to inlining and optimizing, there is a minimal reliable source and type-level information available (more information on a more deep explanation on how to fortify wrapper works on clang [1]). To allow the wrapper to work reliably and with the same functionality as with GCC, clang requires a different approach: * __attribute__((diagnose_if(c, “str”, “warning”))) which is a function level attribute; if the compiler can determine that 'c' is true at compile-time, it will emit a warning with the text 'str1'. If it would be better to emit an error, the wrapper can use "error" instead of "warning". * __attribute__((overloadable)) which is also a function-level attribute; and it allows C++-style overloading to occur on C functions. * __attribute__((pass_object_size(n))) which is a parameter-level attribute; and it makes the compiler evaluate __builtin_object_size(param, n) at each call site of the function that has the parameter, and passes it in as a hidden parameter. This attribute has two side-effects that are key to how FORTIFY works: 1. It can overload solely on pass_object_size (e.g. there are two overloads of foo in void foo(char * __attribute__((pass_object_size(0))) c); void foo(char *); (The one with pass_object_size attribute has precende over the default one). 2. A function with at least one pass_object_size parameter can never have its address taken (and overload resolution respects this). Thus the read wrapper can be implemented as follows, without hindering any fortify coverage compile and runtime: extern __inline __attribute__((__always_inline__)) __attribute__((__artificial__)) __attribute__((__overloadable__)) __attribute__((__warn_unused_result__)) ssize_t read (int __fd, void *const __attribute__((pass_object_size (0))) __buf, size_t __nbytes) __attribute__((__diagnose_if__ ((((__builtin_object_size (__buf, 0)) != -1ULL && (__nbytes) > (__builtin_object_size (__buf, 0)) / (1))), "read called with bigger length than size of the destination buffer", "warning"))) { return (__builtin_object_size (__buf, 0) == (size_t) -1) ? __read_alias (__fd, __buf, __nbytes) : __read_chk (__fd, __buf, __nbytes, __builtin_object_size (__buf, 0)); } To avoid changing the current semantic for GCC, a set of macros is defined to enable the clang required attributes, along with some changes on internal macros to avoid the need to issue the symbol_chk symbols (which are done through the __diagnose_if__ attribute for clang). The read wrapper is simplified as: __fortify_function __attribute_overloadable__ __wur ssize_t read (int __fd, __fortify_clang_overload_arg0 (void *, ,__buf), size_t __nbytes) __fortify_clang_warning_only_if_bos0_lt (__nbytes, __buf, "read called with bigger length than " "size of the destination buffer") { return __glibc_fortify (read, __nbytes, sizeof (char), __glibc_objsize0 (__buf), __fd, __buf, __nbytes); } There is no expected semantic or code change when using GCC. Also, clang does not support __va_arg_pack, so variadic functions are expanded to call va_arg implementations. The error function must not have bodies (address takes are expanded to nonfortified calls), and with the __fortify_function compiler might still create a body with the C++ mangling name (due to the overload attribute). In this case, the function is defined with __fortify_function_error_function macro instead. [1] https://docs.google.com/document/d/1DFfZDICTbL7RqS74wJVIJ-YnjQOj1SaoqfhbgddFYSM/edit Checked on aarch64, armhf, x86_64, and i686. Reviewed-by: Carlos O'Donell Tested-by: Carlos O'Donell

Update copyright dates with scripts/update-copyrights

2024-01-01T18:53:40Z

misc/sys/cdefs.h: Create FORTIFY redirects for internal calls

2023-07-05T14:59:48Z

The __REDIRECT* macros are creating aliases which may lead to unwanted PLT entries when fortification is enabled. To prevent these entries, the REDIRECT alias should be set to point to the existing __GI_* aliases. This is done transparently by creating a __REDIRECT_FORTIFY* version of these macros, that can be overwritten internally when necessary. Reviewed-by: Siddhesh Poyarekar

Added Redirects to longdouble error functions [BZ #29033]

2023-05-10T18:59:48Z

This patch redirects the error functions to the appropriate longdouble variants which enables the compiler to optimize for the abi ieeelongdouble. Signed-off-by: Sachin Monga

cdefs.h: Define __COLD

2023-04-29T15:01:52Z

This expands to __attribute__ ((cold)) when supported. It should be used to mark up functions that are invoked rarely. Signed-off-by: Sergey Bugaev

cdefs.h: fix "__clang_major" typo

2023-02-27T11:18:24Z

* misc/sys/cdefs.h: Fix misspelling of "__clang_major__". Reviewed-by: Adhemerval Zanella