Similar to string2.h (18b10de7ce) and string3.h (09a596cc2c) this
patch removes the fenvinline.h on all architectures. Currently
only powerpc implements some optimizations. This kind of optimization
is better implemented by the compiler (which handles the architecture
ISA transparently).
Also, for the specific optimized powerpc implementation the code is
becoming convoluted and these micro-optimization are hardly wildly
used, even more being a possible hotspot in realword cases
(non-default rounding are used only on specific cases and exception
handling are done most likely only on errors path). Only x86
implements similar optimization (on fenv.h) also indicates that
these should no be on libc.
The math/test-fenv already covers all math/test-fenvinline tests,
so it is safe to remove it.
The powerpc fegetround optimization is moved to internal
fenv_libc.h.
The BZ#94193 [1] the corresponding GCC bug for adding replacements
for these on powerpc.
Checked on x86_64-linux-gnu and powerpc64le-linux-gnu.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94193
Safe-Linking is a security mechanism that protects single-linked
lists (such as the fastbin and tcache) from being tampered by attackers.
The mechanism makes use of randomness from ASLR (mmap_base), and when
combined with chunk alignment integrity checks, it protects the "next"
pointers from being hijacked by an attacker.
While Safe-Unlinking protects double-linked lists (such as the small
bins), there wasn't any similar protection for attacks against
single-linked lists. This solution protects against 3 common attacks:
* Partial pointer override: modifies the lower bytes (Little Endian)
* Full pointer override: hijacks the pointer to an attacker's location
* Unaligned chunks: pointing the list to an unaligned address
The design assumes an attacker doesn't know where the heap is located,
and uses the ASLR randomness to "sign" the single-linked pointers. We
mark the pointer as P and the location in which it is stored as L, and
the calculation will be:
* PROTECT(P) := (L >> PAGE_SHIFT) XOR (P)
* *L = PROTECT(P)
This way, the random bits from the address L (which start at the bit
in the PAGE_SHIFT position), will be merged with LSB of the stored
protected pointer. This protection layer prevents an attacker from
modifying the pointer into a controlled value.
An additional check that the chunks are MALLOC_ALIGNed adds an
important layer:
* Attackers can't point to illegal (unaligned) memory addresses
* Attackers must guess correctly the alignment bits
On standard 32 bit Linux machines, an attack will directly fail 7
out of 8 times, and on 64 bit machines it will fail 15 out of 16
times.
This proposed patch was benchmarked and it's effect on the overall
performance of the heap was negligible and couldn't be distinguished
from the default variance between tests on the vanilla version. A
similar protection was added to Chromium's version of TCMalloc
in 2012, and according to their documentation it had an overhead of
less than 2%.
Reviewed-by: DJ Delorie <dj@redhat.com>
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Reviewed-by: Adhemerval Zacnella <adhemerval.zanella@linaro.org>
On y2038 safe 32-bit systems the Linux kernel expects itimerval to
use a 32-bit time_t, even though the other time_t's are 64-bit. To
address this let's add a __timeval32 struct to be used internally.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
These functions are alpha specifc, rename them to be clear.
Let's also rename the header file from tv32-compat.h to
alpha-tv32-compat.h. This is to avoid conflicts with the one we will
introduce later.
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Some of these files depend on the avoidance of using the various
register sets of POWER. When enabling the IEEE 128 long double,
we must be sure to disable this ABI as some compilers will
refuse to compile if -mno-vsx and -mabi=ieeelongdouble are both
present.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
In practice, this flag should be applied globally, but it makes a good
sanity check to ensure ibm128 and ieee128 long double files are not
getting mismatched. _Float128 files use no long double, thus are
always safe to use this option.
Similarly, when investigating the linker complaints, difftime
makes trivial, self contained, usage of long double, so thus it
is also explicitly marked as such.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
This better resembles the default linking process with the gnulibs,
and also resolves the increasingly difficult to maintain
f128-loader-link usage on powerpc64le as some libgcc symbols are
dependent on those found in the loader (ld).
Ensure the correct ldouble abi flags are applied to ibm128 files and
nldbl files. Remove the IEEE options if used, and apply the flags
used to build ldouble files which are ibm128 abi.
nldbl tests are a little tricky. To use the support, we must remove
all ldouble abi flags, and ensure -mlong-double-64 is used.
Co-authored-by: Rajalakshmi Srinivasaraghavan <raji@linux.vnet.ibm.com>
Co-authored-by: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Co-authored-by: Paul E. Murphy <murphyp@linux.vnet.ibm.com>
The ldbl redirects for ieee128 have some jagged edges when
inspecting and manipulating symbols directly.
e.g asprintf is unconditionally redirected to __asprintfieee128
thus any tests relying on GCC's redirect behavior will encounter
problems if they inspect the symbol names too closely.
I've mitigated tests which expose the limitations of the
ldbl -> f128 redirects by giving them knowledge about the
redirected symbol names.
Hopefully there isn't much user code which depends on this
implementation specific behavior.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Tweak the PLT bypass magic when building glibc with long double
redirects. This is made more difficult by the fact we only get
one chance to redirect functions. This happens via the public
headers.
There are roughly three classes of redirect we need to attend to
today:
1. Simple redirects, redirected via cdef macro overrides and
and new libc_hidden_ldbl_proto macro.
2. Internal usage of internal API, e.g __snprintf, which has
no direct analogue. This is bypassed directly on case-by-
case basis.
3. Double redirects, e.g sscanf and related. These require
a heavier handed approach of macro renaming to existing
symbols.
Most simple redirects are handled via 1. Ideally, the libc_*
macro would live in libc-symbols.h, but in practice the macros
needed for it to do anything useful live in cdefs.h, so they
are defined in the local override.
Notably, the internal name of the asprintf generated for ieee ldbl
redirects is renamed to work with internal prefixed usage.
This resolves the local plt usage introduced when building glibc
with ldbl == ieee128 on ppc64le.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
During the conversion to support 64 bit time on some architectures with
__WORDSIZE == 32 && __TIMESIZE != 64 the libc_hidden_def attribute for
eligible functions was by mistake omitted.
This patch fixes this issue and exports (and allows using) those
functions when Y2038 support is enabled in glibc.
In the "Extended Char Intro" the example incorrectly uses a function
called wgetc which doesn't exist. The example is corrected to use
getwc, which is correct for the use in this case.
Reported-by: Toomas Rosin <toomas@rosin.ee>
This is an updated version of a previous patch [1] with the
following changes:
- Use compiler overflow builtins on done_add_func function.
- Define the scratch +utstring_converted_wide_string using
CHAR_T.
- Added a testcase and mention the bug report.
Both default and wide printf functions might leak memory when
manipulate multibyte characters conversion depending of the size
of the input (whether __libc_use_alloca trigger or not the fallback
heap allocation).
This patch fixes it by removing the extra memory allocation on
string formatting with conversion parts.
The testcase uses input argument size that trigger memory leaks
on unpatched code (using a scratch buffer the threashold to use
heap allocation is lower).
Checked on x86_64-linux-gnu and i686-linux-gnu.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
[1] https://sourceware.org/pipermail/libc-alpha/2017-June/082098.html
With mathinline removal there is no need to keep building and testing
inline math tests.
The gen-libm-tests.py support to generate ULP_I_* is removed and all
libm-test-ulps files are updated to longer have the
i{float,double,ldouble} entries. The support for no-test-inline is
also removed from both gen-auto-libm-tests and the
auto-libm-test-out-* were regenerated.
Checked on x86_64-linux-gnu and i686-linux-gnu.
This is similar to x86 (da75c1b180) and powerpc (32ea729996)
mathinline.h removal. The required macros to build the fpu routines
are moved to mathimpl.h, while the inline optimization macros for
atan, tanh, rint, log1p, significand, trunc, floor, ceil, isinf,
finite, scalbn, isnan, scalbln, nearbyint, lrint, and sincos are removed.
The gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94204 was
created to track builtin support.
Checked with a build against m68k-linux-gnu, resulting binaries
are similar with and without the patch.
Since legacy bitmap doesn't cover jitted code generated by legacy JIT
engine, it isn't very useful. This patch removes ARCH_CET_LEGACY_BITMAP
and treats indirect branch tracking similar to shadow stack by removing
legacy bitmap support.
Tested on CET Linux/x86-64 and non-CET Linux/x86-64.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
On platforms where long double has the same ABI as double, glibc
defines long double functions as aliases for the corresponding double
functions. The declarations of those functions in <math.h> are
disabled to avoid problems with aliases having incompatible types, but
GCC 10 now gives errors for incompatible types when the long double
function is known to GCC as a built-in function, not just when there
is an incompatible header declaration.
This patch fixes those errors by using appropriate
-fno-builtin-<function> options to compile the double functions. The
list of CFLAGS-* settings is an appropriately adapted version of that
in sysdeps/ieee754/ldbl-opt/Makefile used there for building nldbl-*.c
files; in particular, the options are used even if GCC does not
currently have a built-in function of a given function, so that adding
such a built-in function in future will not break the glibc build.
Thus, various of the CFLAGS-* settings are only for future-proofing
and may not currently be needed (and it's possible some could be
irrelevant for other reasons).
Tested with build-many-glibcs.py for arm-linux-gnueabi (compilers and
glibcs builds), where it fixes the build that previously failed.
With this patch, -v turns on a "from" trace for each directory
searched, that tells you WHY that directory is being searched -
is it a builtin, from the command line, or from some config file?
I'm debugging a situation where lots of tests using test-container fail
and it's possible knowing errno would help understand why.
Reviewed-by: DJ Delorie <dj@redhat.com>
Further optimize integer memcpy. Small cases now include copies up
to 32 bytes. 64-128 byte copies are split into two cases to improve
performance of 64-96 byte copies. Comments have been rewritten.
This conversion patch for supporting 64 bit time for futimesat only differs
from the work performed for futimes (when providing __futimes64) with passing
also the file name (and path) to utimensat.
All the design and conversion decisions are exactly the same as for futimens
conversion.
This conversion patch for supporting 64 bit time for lutimes mostly differs from
the work performed for futimes (when providing __futimes64) with adding the
AT_SYMLINK_NOFOLLOW flag to utimensat.
It also supports passing file name instead of file descriptor number, but this
is not relevant for utimensat used to implement it.
All the design and conversion decisions are exactly the same as for futimens
conversion.
This patch provides new __futimes64 explicit 64 bit function for setting file's
64 bit attributes for access and modification time (by specifying file
descriptor number).
Internally, the __utimensat64_helper function is used. This patch is necessary
for having architectures with __WORDSIZE == 32 Y2038 safe.
Moreover, a 32 bit version - __futimes has been refactored to internally use
__futimes64.
The __futimes is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary conversion of struct timeval
to 64 bit struct __timeval64.
The check if struct timevals' usec fields are in the range between 0 and 1000000
has been removed as Linux kernel performs it internally in the implementation
of utimensat (the conversion between struct __timeval64 and __timespec64 is not
relevant for this particular check).
Last but not least, checks for tvp{64} not being NULL have been preserved from
the original code as some legacy user space programs may rely on it.
Build tests:
./src/scripts/build-many-glibcs.py glibcs
Run-time tests:
- Run specific tests on ARM/x86 32bit systems (qemu):
https://github.com/lmajewski/meta-y2038 and run tests:
https://github.com/lmajewski/y2038-tests/commits/master
Above tests were performed with Y2038 redirection applied as well as without to
test the proper usage of both __futimes64 and __futimes.
It seems that some gcc versions might generates a stack frame for the
sigreturn stub requires on sparc signal handling. For instance:
$ cat test.c
#define _GNU_SOURCE
#include <sys/syscall.h>
__attribute__ ((__optimize__ ("-fno-stack-protector")))
void
__sigreturn_stub (void)
{
__asm__ ("mov %0, %%g1\n\t"
"ta 0x10\n\t"
: /* no outputs */
: "i" (SYS_rt_sigreturn));
}
$ gcc -v
[...]
gcc version 9.2.1 20200224 (Debian 9.2.1-30)
$ gcc -O2 -m64 test.c -S -o -
[...]
__sigreturn_stub:
save %sp, -176, %sp
#APP
! 9 "t.c" 1
mov 101, %g1
ta 0x10
! 0 "" 2
#NO_APP
.size __sigreturn_stub, .-__sigreturn_stub
As indicated by kernel developers [1], the sigreturn stub can not change
the register window or the stack pointer since the kernel has setup the
restore frame at a precise location relative to the stack pointer when
the stub is invoked.
I tried to play with some compiler flags and even with _Noreturn and
__builtin_unreachable after the asm does not help (and Sparc does not
support naked functions).
To avoid similar issues, as the stack-protector support also have
stumbled, this patch moves the implementation of the sigreturn stubs to
assembly.
Checked on sparcv9-linux-gnu and sparc64-linux-gnu with gcc 9.2.1
and gcc 7.5.0.
[1] https://lkml.org/lkml/2016/5/27/465
Soon, powerpc64le will need to provide extra compiler flags to the long
double files in order to continue to build using the IBM 128-bit
extended floating point type as long double.
