Add the C23 memset_explicit function to glibc.  Everything here is
closely based on the approach taken for explicit_bzero.  This includes
the bits that relate to internal uses of explicit_bzero within glibc
(although we don't currently have any such internal uses of
memset_explicit), and also includes the nonnull attribute (when we
move to nonnull_if_nonzero for various functions following C2y, this
function should be included in that change).

The function is declared both for __USE_MISC and for __GLIBC_USE (ISOC23)
(so by default not just for compilers defaulting to C23 mode).

Tested for x86_64 and x86.

And add extra checks to enable for binutils 2.45 and if the architecture
explicitly enables it.  When SFrame is disabled, all the related code
is also not enabled for backtrace() and _dl_find_object(), so SFrame
backtracking is not used even if the binary has the SFrame segment.

This patch also adds some other related fixes:

  * Fixed an issue with AC_CHECK_PROG_VER, where the READELF_SFRAME
    usage prevented specifying a different readelf through READELF
    environment variable at configure time.

  * Add an extra arch-specific internal definition,
    libc_cv_support_sframe, to disable --enable-sframe on architectures
    that have binutils but not glibc support (s390x).

  * Renamed the tests without the .sframe segment and move the
    tst-backtrace1 from pthread to debug.

  * Use the built compiler strip to remove the .sframe segment,
    instead of the system one (which might not support SFrame).

Checked on x86_64-linux-gnu and aarch64-linux-gnu.

Reviewed-by: Sam James <sam@gentoo.org>

This test requires relro_format be placed in the PT_GNU_RELRO segment.
The ELF linker enables -z relro support by default on all Linux targets
except FRV, HPPA, IA64 and MIPS. On these targets, we need to explicitly
link with -z relro to place relro_format in the PT_GNU_RELRO segment.

Signed-off-by: John David Anglin <dave.anglin@bell.net>

The _dl_read_only_area function in the uninitialized ld.so after
static dlopen is not able to find anything.  Instead, we need to
redirect to the code from the statically linked main program.

Fixes commit d60fffe28a46b2a41fc308c1804ff02375d27408 ("debug:
Improve '%n' fortify detection (BZ 30932)").

Reviewed-by: Adhemerval Zanella Netto  <adhemerval.zanella@linaro.org>

The test intends to load tst-sprintf-fortify-rdonly-dlopen.so via
dlopen, and directly linking against it prevents that.

Reviewed-by: Adhemerval Zanella Netto  <adhemerval.zanella@linaro.org>

When SFrame is enabled, we need to tests DW backtracer as well. Do
this by executing the same backtrace tests with .sframe section
stripped.

Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>
Reviewed-by: DJ Delorie <dj@redhat.com>

Add function __inet_pton_chk which calls __chk_fail when the size of
argument dst is too small.   inet_pton is redirected to __inet_pton_chk
or __inet_pton_warn when _FORTIFY_SOURCE is > 0.

Also add tests to debug/tst-fortify.c, update the abilist with
__inet_pton_chk and mention inet_pton fortification in maint.texi.

Co-authored-by: Frédéric Bérat <fberat@redhat.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>

The 7bb8045ec0 path made the '%n' fortify check ignore EMFILE errors
while trying to open /proc/self/maps, and this added a security
issue where EMFILE can be attacker-controlled thus making it
ineffective for some cases.

The EMFILE failure is reinstated but with a different error
message.  Also, to improve the false positive of the hardening for
the cases where no new files can be opened, the
_dl_readonly_area now uses  _dl_find_object to check if the
memory area is within a writable ELF segment.  The procfs method is
still used as fallback.

Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Arjun Shankar <arjun@redhat.com>

- Create the __inet_ntop_chk routine that verifies that the builtin size
of the destination buffer is at least as big as the size given by the
user.
- Redirect calls from inet_ntop to __inet_ntop_chk or __inet_ntop_warn
- Update the abilist for this new routine
- Update the manual to mention the new fortification

Reviewed-by: Florian Weimer <fweimer@redhat.com>