Added support for TX lock elision of pthread mutexes on s390 and
s390x. This may improve lock scaling of existing programs on TX
capable systems. The lock elision code is only built with
--enable-lock-elision=yes and then requires a GCC version supporting
the TX builtins. With lock elision default mutexes are elided via
__builtin_tbegin, if the cpu supports transactions. By default lock
elision is not enabled and the elision code is not built.
The SELinux team has indicated to me that glibc's SELinux checks
in nscd are not being carried out as they would expect the API
to be used today. They would like to move away from static header
defines for class and permissions and instead use dynamic checks
at runtime that provide an answer which is dependent on the runtime
status of SELinux i.e. more dynamic.
The following patch is a minimal change that moves us forward in
this direction.
It does the following:
* Stop checking for SELinux headers that define NSCD__SHMEMHOST.
Check only for the presence or absence of the library.
* Don't encode the specific SELinux permission constants into a
table at build time, and instead use the symbolic name for the
permission as expected.
* Lookup the "What do we do if we don't know this permission?"
policy and use that if we find SELinux's policy is older than
the glibc policy e.g. we make a request for a permission that
SELinux doesn't know about.
* Lastly, translate the class and permission and then make
the permission check. This is done every time we lookup
a permission, and this is the expected way to use the API.
SELinux will optimize this for us, and we expect the network
latencies to hide these extra library calls.
Tested on x86, x86-64, and via Fedora Rawhide since November 2013.
See:
https://sourceware.org/ml/libc-alpha/2014-04/msg00179.html
This patch makes the configure adds -D_CALL_ELF=1 when compiler does
not define _CALL_ELF (versions before powerpc64le support). It cleans
up compiler warnings on old compiler where _CALL_ELF is not defined
on powerpc64(be) builds.
It does by add a new config.make variable for configure-deduced
CPPFLAGS and accumulate into that (confix-extra-cppflags). It also
generalizes libc_extra_cflags so it accumulates in sysdeps configure
fragmenets.
Autoconf is tested for and run if needed only when --enable-maintainer-mode
is used on configure. This results in the autom4te.cache directory only
being written in the source directory during configure if automatic
autoconf usage is requested.
Fixes BZ #14120.
Autoconf has been deprecating configure.in for quite a long time.
Rename all our configure.in and preconfigure.in files to .ac.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
http://sourceware.org/ml/libc-alpha/2013-08/msg00096.html
This adds the basic configury bits for powerpc64le and powerpcle.
* configure.in: Map powerpc64le and powerpcle to base_machine/machine.
* configure: Regenerate.
* nptl/shlib-versions: Powerpc*le starts at 2.18.
* shlib-versions: Likewise.
The helper binary pt_chown tricked into granting access to another
user's pseudo-terminal.
Pre-conditions for the attack:
* Attacker with local user account
* Kernel with FUSE support
* "user_allow_other" in /etc/fuse.conf
* Victim with allocated slave in /dev/pts
Using the setuid installed pt_chown and a weak check on whether a file
descriptor is a tty, an attacker could fake a pty check using FUSE and
trick pt_chown to grant ownership of a pty descriptor that the current
user does not own. It cannot access /dev/pts/ptmx however.
In most modern distributions pt_chown is not needed because devpts
is enabled by default. The fix for this CVE is to disable building
and using pt_chown by default. We still provide a configure option
to enable hte use of pt_chown but distributions do so at their own
risk.
Check wheter the compiler has the option -fno-tree-loop-distribute-patterns
to inhibit loop transformation to library calls and uses it on memset
and memmove default implementation to avoid recursive calls.
We no longer support configuring for i386, nor do we
elide such a configuration to i686. Configuring with
i386-* is a failure, and we provide an example of
how to fix that.
---
2013-04-17 Carlos O'Donell <carlos@redhat.com>
* configure.in: Remove i386 configure warning. Remove i386 case.
* configure: Regenerate.
* sysdeps/i386/configure.in: Raise error if config_machine is i386.
Add example to error message.
* sysdeps/i386/configure: Regenerate.
This change does two things:
* Treats a target i386-* as if it were i686.
* Fails configure if the user is generating code
for i386.
We no longer support i386 code-generation because the i386
lacks the atomic operations we need in glibc.
You can still configure for i386-*, but you get i686 code.
You can't build with --march=i386, --mtune=i386 or a compiler
that defaults to i386 code-generation.
I've added two i386 entries in the master todo list to discuss
merging and renaming:
http://sourceware.org/glibc/wiki/Development_Todo/Master#i386
The failure modes are fail-safe here. You compile for i386,
get i686, and try to run on i386 and it fails. The configure
log has a warning saying we elided to i686. There is no situation
that I can see where we run into any serious problems.
The patch makes the current state better in that we get less
confused users and we build successfully in more default
configurations.
The next enhancement would be to add --march=i?86
as suggested in #c20 of BZ#10062 for any i?86-* builds, which
would solve the problem of a 32-bit compiler that defaults to
i386 code-gen and glibc configured for i686-* target. Which
previously failed at build time, and now will fail at configure
time (requires adding --march=i686).
Updated NEWS with BZ #10060 and #10062.
No regressions.
---
2013-04-06 Carlos O'Donell <carlos@redhat.com>
[BZ #10060, #10062]
* aclocal.m4 (LIBC_COMPILER_BUILTIN_INLINED): New macro.
* sysdeps/i386/configure.in: Use LIBC_COMPILER_BUILTIN_INLINED and
fail configure if __sync_val_compare_and_swap is not inlined.
* sysdeps/i386/configure: Regenerate.
* configure.in: Build for i686 when configured for i386.
* configure: Regenerate.
* README: Remove i386 reference.
Stop assuming specific path layouts for C++ headers, and instead
use an autodetection method that looks for paths with '/[cg]++'
in the g++ include list.
The test currently tests the binutils frontend support which passes for
all versions of binutils we currently require (2.20+). It doesn't test
the backend which is required for ifunc to actually work, and which most
targets don't yet support.
Change the assembly code so that when we link it, we get a file that has
ifunc relocations if the backend supports it. That way we can test to
see if binutils supports everything we need.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
