Commit Graph

305 Commits

Author SHA1 Message Date
Adhemerval Zanella
d40ac01cbb stdlib: Make abort/_Exit AS-safe (BZ 26275)
The recursive lock used on abort does not synchronize with a new process
creation (either by fork-like interfaces or posix_spawn ones), nor it
is reinitialized after fork().

Also, the SIGABRT unblock before raise() shows another race condition,
where a fork or posix_spawn() call by another thread, just after the
recursive lock release and before the SIGABRT signal, might create
programs with a non-expected signal mask.  With the default option
(without POSIX_SPAWN_SETSIGDEF), the process can see SIG_DFL for
SIGABRT, where it should be SIG_IGN.

To fix the AS-safe, raise() does not change the process signal mask,
and an AS-safe lock is used if a SIGABRT is installed or the process
is blocked or ignored.  With the signal mask change removal,
there is no need to use a recursive loc.  The lock is also taken on
both _Fork() and posix_spawn(), to avoid the spawn process to see the
abort handler as SIG_DFL.

A read-write lock is used to avoid serialize _Fork and posix_spawn
execution.  Both sigaction (SIGABRT) and abort() requires to lock
as writer (since both change the disposition).

The fallback is also simplified: there is no need to use a loop of
ABORT_INSTRUCTION after _exit() (if the syscall does not terminate the
process, the system is broken).

The proposed fix changes how setjmp works on a SIGABRT handler, where
glibc does not save the signal mask.  So usage like the below will now
always abort.

  static volatile int chk_fail_ok;
  static jmp_buf chk_fail_buf;

  static void
  handler (int sig)
  {
    if (chk_fail_ok)
      {
        chk_fail_ok = 0;
        longjmp (chk_fail_buf, 1);
      }
    else
      _exit (127);
  }
  [...]
  signal (SIGABRT, handler);
  [....]
  chk_fail_ok = 1;
  if (! setjmp (chk_fail_buf))
    {
      // Something that can calls abort, like a failed fortify function.
      chk_fail_ok = 0;
      printf ("FAIL\n");
    }

Such cases will need to use sigsetjmp instead.

The _dl_start_profile calls sigaction through _profil, and to avoid
pulling abort() on loader the call is replaced with __libc_sigaction.

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

Reviewed-by: DJ Delorie <dj@redhat.com>
2024-10-08 14:40:12 -03:00
Adhemerval Zanella
127cefd84d Do not use -Wp to disable fortify (BZ 31928)
The -Wp does not work properly if the compiler is configured to enable
fortify by default, since it bypasses the compiler driver (which defines
the fortify flags in this case).

This patch is similar to the one used on Ubuntu [1].

I checked with a build for x86_64-linux-gnu, i686-linux-gnu,
aarch64-linux-gnu, s390x-linux-gnu, and riscv64-linux-gnu with
gcc-13 that enables the fortify by default.

Co-authored-by: Matthias Klose <matthias.klose@canonical.com>

[1] https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/glibc/tree/debian/patches/ubuntu/fix-fortify-source.patch
Reviewed-by: DJ Delorie <dj@redhat.com>
2024-10-01 08:44:40 -03:00
Florian Weimer
89b088bf70 debug: Fix read error handling in pcprofiledump
The reading loops did not check for read failures.  Addresses
a static analysis report.

Manually tested by compiling a program with the GCC's
-finstrument-functions option, running it with
“LD_PRELOAD=debug/libpcprofile.so PCPROFILE_OUTPUT=output-file”,
and reviewing the output of “debug/pcprofiledump output-file”.
2024-09-10 12:40:27 +02:00
Maciej W. Rozycki
1b97a9f23b support: Add FAIL test failure helper
Add a FAIL test failure helper analogous to FAIL_RET, that does not
cause the current function to return, providing a standardized way to
report a test failure with a message supplied while permitting the
caller to continue executing, for further reporting, cleaning up, etc.

Update existing test cases that provide a conflicting definition of FAIL
by removing the local FAIL definition and then as follows:

- tst-fortify-syslog: provide a meaningful message in addition to the
  file name already added by <support/check.h>; 'support_record_failure'
  is already called by 'support_print_failure_impl' invoked by the new
  FAIL test failure helper.

- tst-ctype: no update to FAIL calls required, with the name of the file
  and the line number within of the failure site additionally included
  by the new FAIL test failure helper, and error counting plus count
  reporting upon test program termination also already provided by
  'support_record_failure' and 'support_report_failure' respectively,
  called by 'support_print_failure_impl' and 'adjust_exit_status' also
  respectively.  However in a number of places 'printf' is called and
  the error count adjusted by hand, so update these places to make use
  of FAIL instead.  And last but not least adjust the final summary just
  to report completion, with any error count following as reported by
  the test driver.

- test-tgmath2: no update to FAIL calls required, with the name of the
  file of the failure site additionally included by the new FAIL test
  failure helper.  Also there is no need to track the return status by
  hand as any call to FAIL will eventually cause the test case to return
  an unsuccesful exit status regardless of the return status from the
  test function, via a call to 'adjust_exit_status' made by the test
  driver.

Reviewed-by: DJ Delorie <dj@redhat.com>
2024-07-26 13:21:34 +01:00
Andreas Schwab
ec6ed525f1 Unify output from backtrace_symbols_fd with backtrace_symbols (bug 31730) 2024-05-14 12:55:06 +02:00
Stefan Liebler
fa3eb7d5e7 string: Add hidden builtin definition for __strcpy_chk.
Otherwise on at least x86_64 and s390x there is an unwanted PLT entry
in libc.so when configured with --enable-fortify-source=3 and build
with -Os.

This is observed in elf/check-localplt
Extra PLT reference: libc.so: __strcpy_chk

The call to PLT entry is in inet/ruserpass.c.
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2024-02-06 09:17:04 +01:00
Frederic Cambus
9fd2ceb55d
debug/getwd_chk.c: warning should be emitted for the __getwd_chk symbol.
Otherwise the warning message for the getwd symbol ends up being duplicated.

Signed-off-by: Frederic Cambus <fred@statdns.com>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
2024-01-12 15:21:26 +01:00
Paul Eggert
1059defeee Update copyright dates not handled by scripts/update-copyrights
I've updated copyright dates in glibc for 2024.  This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files.
2024-01-01 10:53:40 -08:00
Paul Eggert
dff8da6b3e Update copyright dates with scripts/update-copyrights 2024-01-01 10:53:40 -08:00
Adhemerval Zanella
a8a4c94ae9 debug: Add fortify wprintf tests
Similar to other printf-like ones.  It requires to be in a different
process so we can change the orientation of stdout.

Checked on aarch64, armhf, x86_64, and i686.
2023-12-29 10:57:27 -03:00
Adhemerval Zanella
446e2c935a debug: Add fortify syslog tests
It requires to be in a container tests to avoid logging bogus
information on the system.  The syslog also requires to be checked in
a different process because the internal printf call will abort with
the internal syslog lock taken (which makes subsequent syslog calls
deadlock).

Checked on aarch64, armhf, x86_64, and i686.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-29 10:57:03 -03:00
Adhemerval Zanella
121aad59de debug: Add fortify dprintf tests
Similar to other printf-like ones.

Checked on aarch64, armhf, x86_64, and i686.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-29 10:57:03 -03:00
Adhemerval Zanella
bf320000b4 debug: Increase tst-fortify checks for compiler without __va_arg_pack support
The fortify wrappers for varargs functions already add fallbacks to
builtins calls if __va_arg_pack is not supported.

Checked on aarch64, armhf, x86_64, and i686.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-29 10:57:03 -03:00
Adhemerval Zanella
9556acd249 debug: Adapt fortify tests to libsupport
Checked on aarch64, armhf, x86_64, and i686.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-12-29 10:57:03 -03:00
Adhemerval Zanella
be7a5468d4 debug: Add regression tests for BZ 30932
Checked on x86_64-linux-gnu.
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-10-04 08:07:43 -03:00
Samuel Thibault
04bf7d2d8a chk: Add and fix hidden builtin definitions for *_chk
Otherwise on gnu-i686 there are unwanted PLT entries in libc.so when
fortification is enabled.

Tested for i686-gnu, x86_64-gnu, i686-linux-gnu and x86_64-linux-gnu
2023-08-03 22:46:48 +02:00
Samuel Thibault
2345bc44bb Subject: hurd: Make __realpath return EINVAL on NULL buf
As Posix and stdlib/test-canon.c expects it, and rather than letting
pathconf crash.
2023-08-03 22:42:29 +02:00
Frédéric Bérat
d9a99272d2 misc/bits/select2.h: Clearly separate declaration from definitions
The __fdelt_chk declaration needs to be available so that
libc_hidden_proto can be used while not redefining __FD_ELT.
Thus, misc/bits/select-decl.h is created to hold the corresponding
prototypes.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-07-05 16:59:48 +02:00
Frédéric Bérat
b17d65ff92 unistd: Avoid PLT entries with _FORTIFY_SOURCE
The change is meant to avoid unwanted PLT entries for the read_chk,
getdomainname_chk and getlogin_r_chk routines when _FORTIFY_SOURCE is set.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-07-05 16:59:48 +02:00
Frédéric Bérat
64f9857507 wchar: Avoid PLT entries with _FORTIFY_SOURCE
The change is meant to avoid unwanted PLT entries for the wmemset and
wcrtomb routines when _FORTIFY_SOURCE is set.

On top of that, ensure that *_chk routines have their hidden builtin
definitions available.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-07-05 16:59:48 +02:00
Frédéric Bérat
505c884aeb stdio: Ensure *_chk routines have their hidden builtin definition available
If libc_hidden_builtin_{def,proto} isn't properly set for *_chk routines,
there are unwanted PLT entries in libc.so.

There is a special case with __asprintf_chk:
If ldbl_* macros are used for asprintf, ABI gets broken on s390x,
if it isn't, ppc64le isn't building due to multiple asm redirections.

This is due to the inclusion of bits/stdio-lbdl.h for ppc64le whereas it
isn't for s390x. This header creates redirections, which are not
compatible with the ones generated using libc_hidden_def.
Yet, we can't use libc_hidden_ldbl_proto on s390x since it will not
create a simple strong alias (e.g. as done on x86_64), but a versioned
alias, leading to ABI breakage.

This results in errors on s390x:
/usr/bin/ld: glibc/iconv/../libio/bits/stdio2.h:137: undefined reference
to `__asprintf_chk'

Original __asprintf_chk symbols:
00000000001395b0 T __asprintf_chk
0000000000177e90 T __nldbl___asprintf_chk

__asprintf_chk symbols with ldbl_* macros:
000000000012d590 t ___asprintf_chk
000000000012d590 t __asprintf_chk@@GLIBC_2.4
000000000012d590 t __GI___asprintf_chk
000000000012d590 t __GL____asprintf_chk___asprintf_chk
0000000000172240 T __nldbl___asprintf_chk

__asprintf_chk symbols with the patch:
000000000012d590 t ___asprintf_chk
000000000012d590 T __asprintf_chk
000000000012d590 t __GI___asprintf_chk
0000000000172240 T __nldbl___asprintf_chk

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2023-07-05 16:59:48 +02:00
Frédéric Bérat
dd8486ffc1 string: Ensure *_chk routines have their hidden builtin definition available
If libc_hidden_builtin_{def,proto} isn't properly set for *_chk routines,
there are unwanted PLT entries in libc.so.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-07-05 16:59:48 +02:00
Frédéric Bérat
20c894d21e Exclude routines from fortification
Since the _FORTIFY_SOURCE feature uses some routines of Glibc, they need to
be excluded from the fortification.

On top of that:
 - some tests explicitly verify that some level of fortification works
   appropriately, we therefore shouldn't modify the level set for them.
 - some objects need to be build with optimization disabled, which
   prevents _FORTIFY_SOURCE to be used for them.

Assembler files that implement architecture specific versions of the
fortified routines were not excluded from _FORTIFY_SOURCE as there is no
C header included that would impact their behavior.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-07-05 16:59:48 +02:00
Frederic Berat
0371c23623 debug/readlink{, at}_chk.c: Harmonize declaration and definition
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-22 00:21:06 -04:00
Florian Weimer
b54e5d1c92 Add the wcslcpy, wcslcat functions
These functions are about to be added to POSIX, under Austin Group
issue 986.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-14 18:10:24 +02:00
Florian Weimer
454a20c875 Implement strlcpy and strlcat [BZ #178]
These functions are about to be added to POSIX, under Austin Group
issue 986.

The fortified strlcat implementation does not raise SIGABRT if the
destination buffer does not contain a null terminator, it just
inherits the non-failing regular strlcat behavior.

Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2023-06-14 18:10:08 +02:00
Paul Pluzhnikov
7f0d9e61f4 Fix all the remaining misspellings -- BZ 25337 2023-06-02 01:39:48 +00:00
Carlos O'Donell
e475bc2507 debug: Reformat Makefile.
Fix list terminator whitspace.
Sort using scripts/sort-makefile-lines.py.

No code generation changes observed in binary artifacts.
No regressions on x86_64 and i686.
2023-05-16 07:17:19 -04:00
Florian Weimer
4e4641164d debug: Re-flow and sort routines variable in Makefile
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2023-04-17 16:00:58 +02:00
Florian Weimer
0d50f477f4 stdio-common: Handle -1 buffer size in __sprintf_chk & co (bug 30039)
This shows up as an assertion failure when sprintf is called with
a specifier like "%.8g" and libquadmath is linked in:

Fatal glibc error: printf_buffer_as_file.c:31
  (__printf_buffer_as_file_commit): assertion failed:
  file->stream._IO_write_ptr <= file->next->write_end

Fix this by detecting pointer wraparound in __vsprintf_internal
and saturate the addition to the end of the address space instead.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Tested-by: Carlos O'Donell <carlos@redhat.com>
2023-01-25 08:01:00 +01:00
Joseph Myers
ae612c45ef Update copyright dates not handled by scripts/update-copyrights
I've updated copyright dates in glibc for 2023.  This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files.
2023-01-06 21:45:36 +00:00
Joseph Myers
6d7e8eda9b Update copyright dates with scripts/update-copyrights 2023-01-06 21:14:39 +00:00
Adhemerval Zanella
1a8335a408 debug: Fix typo in tests-unsupported rule
From commit 2e274cd8c1.
2022-11-09 11:24:45 -03:00
Adhemerval Zanella
2e274cd8c1 Linux: Add ppoll fortify symbol for 64 bit time_t (BZ# 29746)
Similar to ppoll, the poll.h header needs to redirect the poll call
to a proper fortified ppoll with 64 bit time_t support.

The implementation is straightforward, just need to add a similar
check as __poll_chk and call the 64 bit time_t ppoll version.  The
debug fortify tests are also extended to cover 64 bit time_t for
affected ABIs.

Unfortunately it requires an aditional symbol, which makes backport
tricky.  One possibility is to add a static inline version if compiler
supports is and call abort instead of __chk_fail, so fortified version
will call __poll64 in the end.

Another possibility is to just remove the fortify support for
_TIME_BITS=64.

Checked on i686-linux-gnu.
2022-11-08 13:37:06 -03:00
Szabolcs Nagy
3fa20d59d9 Fix invalid pointer dereference in wcpcpy_chk
The src pointer is const and points to a different object, so accessing
dest via src is invalid.

Reviewed-by: Florian Weimer <fweimer@redhat.com>
2022-10-28 11:15:28 +01:00
Szabolcs Nagy
e5ece9de14 Fix invalid pointer dereference in wcscpy_chk
The src pointer is const and points to a different object, so accessing
dest via src is invalid.

Reviewed-by: Florian Weimer <fweimer@redhat.com>
2022-10-28 11:15:28 +01:00
Adhemerval Zanella
cd84e30c04 debug: test for more required cacellation points (BZ# 29274)
Generalize the test for cancellation point in __read_chk to also test
the other fortified functions with required cancellation points.

Since there is not easy way to force some syscalls to block (for
instance pread) the test tests two modes: cancellation on blocked
syscalls and early cancellation on pending request.

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

Co-authored-by: Andreas Schwab <schwab@suse.de>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2022-09-05 10:47:34 -03:00
Florian Weimer
cca9684f2d stdio: Clean up __libc_message after unconditional abort
Since commit ec2c1fcefb ("malloc:
Abort on heap corruption, without a backtrace [BZ #21754]"),
__libc_message always terminates the process.  Since commit
a289ea09ea ("Do not print backtraces
on fatal glibc errors"), the backtrace facility has been removed.
Therefore, remove enum __libc_message_action and the action
argument of __libc_message, and mark __libc_message as _No_return.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2022-08-03 11:42:39 +02:00
Andreas Schwab
dc30acf20b debug: make __read_chk a cancellation point (bug 29274)
The __read_chk function, as the implementation behind the fortified read
function, must be a cancellation point, thus it cannot use INLINE_SYSCALL.
2022-06-22 17:00:44 +02:00
Siddhesh Poyarekar
9bcd12d223 wcrtomb: Make behavior POSIX compliant
The GNU implementation of wcrtomb assumes that there are at least
MB_CUR_MAX bytes available in the destination buffer passed to wcrtomb
as the first argument.  This is not compatible with the POSIX
definition, which only requires enough space for the input wide
character.

This does not break much in practice because when users supply buffers
smaller than MB_CUR_MAX (e.g. in ncurses), they compute and dynamically
allocate the buffer, which results in enough spare space (thanks to
usable_size in malloc and padding in alloca) that no actual buffer
overflow occurs.  However when the code is built with _FORTIFY_SOURCE,
it runs into the hard check against MB_CUR_MAX in __wcrtomb_chk and
hence fails.  It wasn't evident until now since dynamic allocations
would result in wcrtomb not being fortified but since _FORTIFY_SOURCE=3,
that limitation is gone, resulting in such code failing.

To fix this problem, introduce an internal buffer that is MB_LEN_MAX
long and use that to perform the conversion and then copy the resultant
bytes into the destination buffer.  Also move the fortification check
into the main implementation, which checks the result after conversion
and aborts if the resultant byte count is greater than the destination
buffer size.

One complication is that applications that assume the MB_CUR_MAX
limitation to be gone may not be able to run safely on older glibcs if
they use static destination buffers smaller than MB_CUR_MAX; dynamic
allocations will always have enough spare space that no actual overruns
will occur.  One alternative to fixing this is to bump symbol version to
prevent them from running on older glibcs but that seems too strict a
constraint.  Instead, since these users will only have made this
decision on reading the manual, I have put a note in the manual warning
them about the pitfalls of having static buffers smaller than
MB_CUR_MAX and running them on older glibc.

Benchmarking:

The wcrtomb microbenchmark shows significant increases in maximum
execution time for all locales, ranging from 10x for ar_SA.UTF-8 to
1.5x-2x for nearly everything else.  The mean execution time however saw
practically no impact, with some results even being quicker, indicating
that cache locality has a much bigger role in the overhead.

Given that the additional copy uses a temporary buffer inside wcrtomb,
it's likely that a hot path will end up putting that buffer (which is
responsible for the additional overhead) in a similar place on stack,
giving the necessary cache locality to negate the overhead.  However in
situations where wcrtomb ends up getting called at wildly different
spots on the call stack (or is on different call stacks, e.g. with
threads or different execution contexts) and is still a hotspot, the
performance lag will be visible.

Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2022-05-13 19:15:46 +05:30
Joan Bruguera
33e03f9cd2 misc: Fix rare fortify crash on wchar funcs. [BZ 29030]
If `__glibc_objsize (__o) == (size_t) -1` (i.e. `__o` is unknown size), fortify
checks should pass, and `__whatever_alias` should be called.

Previously, `__glibc_objsize (__o) == (size_t) -1` was explicitly checked, but
on commit a643f60c53, this was moved into `__glibc_safe_or_unknown_len`.

A comment says the -1 case should work as: "The -1 check is redundant because
since it implies that __glibc_safe_len_cond is true.". But this fails when:
* `__s > 1`
* `__osz == -1` (i.e. unknown size at compile time)
* `__l` is big enough
* `__l * __s <= __osz` can be folded to a constant
(I only found this to be true for `mbsrtowcs` and other functions in wchar2.h)

In this case `__l * __s <= __osz` is false, and `__whatever_chk_warn` will be
called by `__glibc_fortify` or `__glibc_fortify_n` and crash the program.

This commit adds the explicit `__osz == -1` check again.
moc crashes on startup due to this, see: https://bugs.archlinux.org/task/74041

Minimal test case (test.c):
    #include <wchar.h>

    int main (void)
    {
        const char *hw = "HelloWorld";
        mbsrtowcs (NULL, &hw, (size_t)-1, NULL);
        return 0;
    }

Build with:
    gcc -O2 -Wp,-D_FORTIFY_SOURCE=2 test.c -o test && ./test

Output:
    *** buffer overflow detected ***: terminated

Fixes: BZ #29030
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2022-04-25 17:32:30 +05:30
Cristian Rodríguez
811c635dba debug: Improve fdelt_chk error message
It is not a "buffer overflow detected" but an out of range
bit on fd_set

Signed-off-by: Cristian Rodríguez <crrodriguez@opensuse.org>
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
2022-03-28 19:10:30 +05:30
Siddhesh Poyarekar
fcfc908681 debug: Synchronize feature guards in fortified functions [BZ #28746]
Some functions (e.g. stpcpy, pread64, etc.) had moved to POSIX in the
main headers as they got incorporated into the standard, but their
fortified variants remained under __USE_GNU.  As a result, these
functions did not get fortified when _GNU_SOURCE was not defined.

Add test wrappers that check all functions tested in tst-chk0 at all
levels with _GNU_SOURCE undefined and then use the failures to (1)
exclude checks for _GNU_SOURCE functions in these tests and (2) Fix
feature macro guards in the fortified function headers so that they're
the same as the ones in the main headers.

This fixes BZ #28746.

Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2022-01-12 23:34:48 +05:30
Siddhesh Poyarekar
db27f1251b debug: Autogenerate _FORTIFY_SOURCE tests
Rename debug/tst-chk1.c to debug/tst-fortify.c and add make hackery to
autogenerate tests with different macros enabled to build and run the
same test with different configurations as well as different
fortification levels.

The change also ends up expanding the -lfs tests to include
_FORTIFY_SOURCE=3.

Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2022-01-12 23:34:23 +05:30
Adhemerval Zanella
65ccd641ba debug: Remove catchsegv and libSegfault (BZ #14913)
Trapping SIGSEGV within the process is error-prone, adds security
issues, and modern analysis design tends to happen out of the
process (either by attaching a debugger or by post-mortem analysis).

The libSegfault also has some design problems, it uses non
async-signal-safe function (backtrace) on signal handler.

There are multiple alternatives if users do want to use similar
functionality, such as sigsegv gnulib module or libsegfault.
2022-01-06 07:59:49 -03:00
Paul Eggert
634b5ebac6 Update copyright dates not handled by scripts/update-copyrights.
I've updated copyright dates in glibc for 2022.  This is the patch for
the changes not generated by scripts/update-copyrights and subsequent
build / regeneration of generated files.  As well as the usual annual
updates, mainly dates in --version output (minus csu/version.c which
previously had to be handled manually but is now successfully updated
by update-copyrights), there is a small change to the copyright notice
in NEWS which should let NEWS get updated automatically next year.

Please remember to include 2022 in the dates for any new files added
in future (which means updating any existing uncommitted patches you
have that add new files to use the new copyright dates in them).
2022-01-01 11:42:26 -08:00
Paul Eggert
581c785bf3 Update copyright dates with scripts/update-copyrights
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
2022-01-01 11:40:24 -08:00
Siddhesh Poyarekar
2bbd07c715 fortify: Fix spurious warning with realpath
The length and object size arguments were swapped around for realpath.
Also add a smoke test so that any changes in this area get caught in
future.

Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
2021-12-17 18:49:27 +05:30
Siddhesh Poyarekar
ad6f2a010c debug: Add tests for _FORTIFY_SOURCE=3
Add some testing coverage for _FORTIFY_SOURCE=3.

Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2021-10-20 18:13:05 +05:30
Siddhesh Poyarekar
30891f35fa Remove "Contributed by" lines
We stopped adding "Contributed by" or similar lines in sources in 2012
in favour of git logs and keeping the Contributors section of the
glibc manual up to date.  Removing these lines makes the license
header a bit more consistent across files and also removes the
possibility of error in attribution when license blocks or files are
copied across since the contributed-by lines don't actually reflect
reality in those cases.

Move all "Contributed by" and similar lines (Written by, Test by,
etc.) into a new file CONTRIBUTED-BY to retain record of these
contributions.  These contributors are also mentioned in
manual/contrib.texi, so we just maintain this additional record as a
courtesy to the earlier developers.

The following scripts were used to filter a list of files to edit in
place and to clean up the CONTRIBUTED-BY file respectively.  These
were not added to the glibc sources because they're not expected to be
of any use in future given that this is a one time task:

https://gist.github.com/siddhesh/b5ecac94eabfd72ed2916d6d8157e7dc
https://gist.github.com/siddhesh/15ea1f5e435ace9774f485030695ee02

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2021-09-03 22:06:44 +05:30