public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
* [glibc/nsz/pacbti-v6] aarch64: ensure objects are BTI compatible
@ 2020-07-01 14:33 Szabolcs Nagy
0 siblings, 0 replies; 2+ messages in thread
From: Szabolcs Nagy @ 2020-07-01 14:33 UTC (permalink / raw)
To: glibc-cvs
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=d70b0013e7348d11bc819854861365c2ee59a35f
commit d70b0013e7348d11bc819854861365c2ee59a35f
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Tue Jun 30 11:12:40 2020 +0100
aarch64: ensure objects are BTI compatible
When glibc is built with branch protection (i.e. with a gcc configured
with --enable-standard-branch-protection), all glibc binaries should
be BTI compatible and marked as such.
It is easy to link BTI incompatible objects by accident and this is
silent currently which is usually not the expectation, so this is
changed into a link error. (There is no linker flag for failing on
BTI incompatible inputs so all warnings are turned into fatal errors
outside the test system when building glibc with branch protection.)
Unfortunately, outlined atomic functions are not BTI compatible in
libgcc (PR libgcc/96001), so to build glibc with current gcc use
'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon
and then glibc can be built and tested without such workarounds.
Diff:
---
sysdeps/aarch64/Makefile | 8 ++++++++
sysdeps/aarch64/configure | 2 ++
sysdeps/aarch64/configure.ac | 1 +
3 files changed, 11 insertions(+)
diff --git a/sysdeps/aarch64/Makefile b/sysdeps/aarch64/Makefile
index 5ae8b082b0..7f82fc055e 100644
--- a/sysdeps/aarch64/Makefile
+++ b/sysdeps/aarch64/Makefile
@@ -1,5 +1,13 @@
long-double-fcts = yes
+ifeq (yes,$(aarch64-bti))
+# Mark linker output BTI compatible, it warns on non-BTI inputs.
+sysdep-LDFLAGS += -Wl,-z,force-bti
+# Make warnings fatal outside the test system.
+LDFLAGS-lib.so += -Wl,--fatal-warnings
+LDFLAGS-rtld += -Wl,-z,force-bti,--fatal-warnings
+endif
+
ifeq ($(subdir),elf)
sysdep-dl-routines += dl-bti
endif
diff --git a/sysdeps/aarch64/configure b/sysdeps/aarch64/configure
index 70477a7fa5..c637540436 100644
--- a/sysdeps/aarch64/configure
+++ b/sysdeps/aarch64/configure
@@ -210,6 +210,8 @@ EOF
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_aarch64_bti" >&5
$as_echo "$libc_cv_aarch64_bti" >&6; }
+config_vars="$config_vars
+aarch64-bti = $libc_cv_aarch64_bti"
if test $libc_cv_aarch64_bti = yes; then
$as_echo "#define HAVE_AARCH64_BTI 1" >>confdefs.h
diff --git a/sysdeps/aarch64/configure.ac b/sysdeps/aarch64/configure.ac
index 798f494740..2c2817514d 100644
--- a/sysdeps/aarch64/configure.ac
+++ b/sysdeps/aarch64/configure.ac
@@ -36,6 +36,7 @@ EOF
libc_cv_aarch64_bti=yes
fi
rm -rf conftest.*])
+LIBC_CONFIG_VAR([aarch64-bti], [$libc_cv_aarch64_bti])
if test $libc_cv_aarch64_bti = yes; then
AC_DEFINE(HAVE_AARCH64_BTI)
fi
^ permalink raw reply [flat|nested] 2+ messages in thread
* [glibc/nsz/pacbti-v6] aarch64: ensure objects are BTI compatible
@ 2020-07-02 8:38 Szabolcs Nagy
0 siblings, 0 replies; 2+ messages in thread
From: Szabolcs Nagy @ 2020-07-02 8:38 UTC (permalink / raw)
To: glibc-cvs
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=52733817c888141129929df79dad7704ed44e335
commit 52733817c888141129929df79dad7704ed44e335
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Tue Jun 30 11:12:40 2020 +0100
aarch64: ensure objects are BTI compatible
When glibc is built with branch protection (i.e. with a gcc configured
with --enable-standard-branch-protection), all glibc binaries should
be BTI compatible and marked as such.
It is easy to link BTI incompatible objects by accident and this is
silent currently which is usually not the expectation, so this is
changed into a link error. (There is no linker flag for failing on
BTI incompatible inputs so all warnings are turned into fatal errors
outside the test system when building glibc with branch protection.)
Unfortunately, outlined atomic functions are not BTI compatible in
libgcc (PR libgcc/96001), so to build glibc with current gcc use
'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon
and then glibc can be built and tested without such workarounds.
Diff:
---
sysdeps/aarch64/Makefile | 8 ++++++++
sysdeps/aarch64/configure | 2 ++
sysdeps/aarch64/configure.ac | 1 +
3 files changed, 11 insertions(+)
diff --git a/sysdeps/aarch64/Makefile b/sysdeps/aarch64/Makefile
index 5ae8b082b0..7f82fc055e 100644
--- a/sysdeps/aarch64/Makefile
+++ b/sysdeps/aarch64/Makefile
@@ -1,5 +1,13 @@
long-double-fcts = yes
+ifeq (yes,$(aarch64-bti))
+# Mark linker output BTI compatible, it warns on non-BTI inputs.
+sysdep-LDFLAGS += -Wl,-z,force-bti
+# Make warnings fatal outside the test system.
+LDFLAGS-lib.so += -Wl,--fatal-warnings
+LDFLAGS-rtld += -Wl,-z,force-bti,--fatal-warnings
+endif
+
ifeq ($(subdir),elf)
sysdep-dl-routines += dl-bti
endif
diff --git a/sysdeps/aarch64/configure b/sysdeps/aarch64/configure
index 70477a7fa5..c637540436 100644
--- a/sysdeps/aarch64/configure
+++ b/sysdeps/aarch64/configure
@@ -210,6 +210,8 @@ EOF
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_cv_aarch64_bti" >&5
$as_echo "$libc_cv_aarch64_bti" >&6; }
+config_vars="$config_vars
+aarch64-bti = $libc_cv_aarch64_bti"
if test $libc_cv_aarch64_bti = yes; then
$as_echo "#define HAVE_AARCH64_BTI 1" >>confdefs.h
diff --git a/sysdeps/aarch64/configure.ac b/sysdeps/aarch64/configure.ac
index 798f494740..2c2817514d 100644
--- a/sysdeps/aarch64/configure.ac
+++ b/sysdeps/aarch64/configure.ac
@@ -36,6 +36,7 @@ EOF
libc_cv_aarch64_bti=yes
fi
rm -rf conftest.*])
+LIBC_CONFIG_VAR([aarch64-bti], [$libc_cv_aarch64_bti])
if test $libc_cv_aarch64_bti = yes; then
AC_DEFINE(HAVE_AARCH64_BTI)
fi
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-07-02 8:38 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-01 14:33 [glibc/nsz/pacbti-v6] aarch64: ensure objects are BTI compatible Szabolcs Nagy
2020-07-02 8:38 Szabolcs Nagy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).