glibc/libio/bits/stdio2.h, branch vdso

Fix name space violation in fortify wrappers (bug 32052)

2024-08-05T14:49:58Z

Rename the identifier sz to __sz everywhere. Fixes: a643f60c53 ("Make sure that the fortified function conditionals are constant")

libio: Improve fortify with clang

2024-02-27T13:52:58Z

It improve fortify checks for sprintf, vsprintf, vsnsprintf, fprintf, dprintf, asprintf, __asprintf, obstack_printf, gets, fgets, fgets_unlocked, fread, and fread_unlocked. The runtime checks have similar support coverage as with GCC. For function with variadic argument (sprintf, snprintf, fprintf, printf, dprintf, asprintf, __asprintf, obstack_printf) the fortify wrapper calls the va_arg version since clang does not support __va_arg_pack. 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

libio: Add nonnull attribute for most FILE * arguments in stdio.h

2023-09-27T00:11:38Z

During the review of a GCC analyzer test case, we found most stdio functions accepting a FILE * argument expect it to be nonnull and just segfault when the argument is NULL. Add nonnull attribute for them. fflush and fflush_unlocked are well defined when __stream is NULL so they are not touched. For fputs, fgets, fread, fwrite, fprintf, vfprintf, and their unlocked version, if __stream is empty but there is nothing to read or write, they did not segfault. But the standard disallow __stream to be empty here, so nonnull attribute is also added for them. Note that this may blow up some old code already subtly broken. Also add __nonnull for _chk variants and __fortify_function versions for them. Signed-off-by: Xi Ruoyao Reviewed-by: Alejandro Colomar Reviewed-by: Siddhesh Poyarekar

libio/bits/stdio2.h: Clearly separate declaration from definitions

2023-07-05T14:59:48Z

Move declarations from libio/bits/stdio.h to existing libio/bits/stdio2-decl.h. This will enable future use of __REDIRECT_FORTIFY in place of some __REDIRECT. Reviewed-by: Siddhesh Poyarekar

Update copyright dates with scripts/update-copyrights

2023-01-06T21:14:39Z

Apply asm redirections in stdio.h before first use [BZ #27087]

2022-07-14T19:01:14Z

Compilers may not be able to apply asm redirections to functions after these functions are used for the first time, e.g. clang 13. Fix [BZ #27087] by applying all long double-related asm redirections before using functions in bits/stdio.h. However, as these asm redirections depend on the declarations provided by libio/bits/stdio2.h, this header was split in 2: - libio/bits/stdio2-decl.h contains all function declarations; - libio/bits/stdio2.h remains with the remaining contents, including redirections. This also adds the access attribute to __vsnprintf_chk that was missing. Tested with build-many-glibcs.py. Reviewed-by: Paul E. Murphy

Update copyright dates with scripts/update-copyrights

2022-01-01T19:40:24Z

I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: *** 912-#endif remote: *** 913: remote: *** 914- remote: *** error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines

Make sure that the fortified function conditionals are constant

2021-10-20T12:42:41Z

In _FORTIFY_SOURCE=3, the size expression may be non-constant, resulting in branches in the inline functions remaining intact and causing a tiny overhead. Clang (and in future, gcc) make sure that the -1 case is always safe, i.e. any comparison of the generated expression with (size_t)-1 is always false so that bit is taken care of. The rest is avoidable since we want the _chk variant whenever we have a size expression and it's not -1. Rework the conditionals in a uniform way to clearly indicate two conditions at compile time: - Either the size is unknown (-1) or we know at compile time that the operation length is less than the object size. We can call the original function in this case. It could be that either the length, object size or both are non-constant, but the compiler, through range analysis, is able to fold the *comparison* to a constant. - The size and length are known and the compiler can see at compile time that operation length > object size. This is valid grounds for a warning at compile time, followed by emitting the _chk variant. For everything else, emit the _chk variant. This simplifies most of the fortified function implementations and at the same time, ensures that only one call from _chk or the regular function is emitted. Signed-off-by: Siddhesh Poyarekar Reviewed-by: Adhemerval Zanella

Don't add access size hints to fortifiable functions

2021-10-20T03:03:31Z

In the context of a function definition, the size hints imply that the size of an object pointed to by one parameter is another parameter. This doesn't make sense for the fortified versions of the functions since that's the bit it's trying to validate. This is harmless with __builtin_object_size since it has fairly simple semantics when it comes to objects passed as function parameters. With __builtin_dynamic_object_size we could (as my patchset for gcc[1] already does) use the access attribute to determine the object size in the general case but it misleads the fortified functions. Basically the problem occurs when access attributes are present on regular functions that have inline fortified definitions to generate _chk variants; the attributes get inherited by these definitions, causing problems when analyzing them. For example with poll(fds, nfds, timeout), nfds is hinted using the __attr_access as being the size of fds. Now, when analyzing the inline function definition in bits/poll2.h, the compiler sees that nfds is the size of fds and tries to use that information in the function body. In _FORTIFY_SOURCE=3 case, where the object size could be a non-constant expression, this information results in the conclusion that nfds is the size of fds, which defeats the purpose of the implementation because we're trying to check here if nfds does indeed represent the size of fds. Hence for this case, it is best to not have the access attribute. With the attributes gone, the expression evaluation should get delayed until the function is actually inlined into its destinations. Disable the access attribute for fortified function inline functions when building at _FORTIFY_SOURCE=3 to make this work better. The access attributes remain for the _chk variants since they can be used by the compiler to warn when the caller is passing invalid arguments. [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581125.html Signed-off-by: Siddhesh Poyarekar