public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
* [glibc/nsz/pacbti-v6] (14 commits) aarch64: add NEWS entry about branch protection support
@ 2020-07-02 8:38 Szabolcs Nagy
0 siblings, 0 replies; only message in thread
From: Szabolcs Nagy @ 2020-07-02 8:38 UTC (permalink / raw)
To: glibc-cvs
The branch 'nsz/pacbti-v6' was updated to point to:
1be15b1c45... aarch64: add NEWS entry about branch protection support
It previously pointed to:
94342f2e1c... aarch64: add NEWS entry about branch protection support
Diff:
!!! WARNING: THE FOLLOWING COMMITS ARE NO LONGER ACCESSIBLE (LOST):
-------------------------------------------------------------------
94342f2... aarch64: add NEWS entry about branch protection support
3354b73... aarch64: redefine RETURN_ADDRESS to strip PAC
6912a89... aarch64: fix pac-ret support in _mcount
fe35e07... aarch64: Add pac-ret support to assembly files
e5a6ef5... aarch64: configure check for pac-ret code generation
d70b001... aarch64: ensure objects are BTI compatible
2d49a4f... aarch64: enable BTI at runtime
703df8e... rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handling
61533cc... aarch64: fix RTLD_START for BTI
90584dd... aarch64: fix swapcontext for BTI
80723d0... aarch64: Add BTI support to assembly files
f76a919... aarch64: Rename place holder .S files to .c
cf32244... aarch64: configure test for BTI support
cf429c3... Rewrite abi-note.S in C.
commit 94342f2e1cfb24b4830e7f5aed96882cd0981dee
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Thu Jun 11 18:19:40 2020 +0100
aarch64: add NEWS entry about branch protection support
This is a new security feature that relies on architecture
extensions and needs glibc to be built with a gcc configured
with branch protection.
commit 3354b735255589858af1eaa23867c4f1ac0c65fb
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 15 17:40:45 2020 +0100
aarch64: redefine RETURN_ADDRESS to strip PAC
RETURN_ADDRESS is used at several places in glibc to mean a valid
code address of the call site, but with pac-ret it may contain a
pointer authentication code (PAC), so its definition is adjusted.
This is gcc PR target/94891: __builtin_return_address should not
expose signed pointers to user code where it can cause ABI issues.
In glibc RETURN_ADDRESS is only changed if it is built with pac-ret.
There is no detection for the specific gcc issue because it is
hard to test and the additional xpac does not cause problems.
commit 6912a894dcd66e24305e089d4c6de3c1b80e4cee
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed May 13 12:10:13 2020 +0100
aarch64: fix pac-ret support in _mcount
Currently gcc -pg -mbranch-protection=pac-ret passes signed return
address to _mcount, so _mcount now has to always strip pac from the
frompc since that's from user code that may be built with pac-ret.
This is gcc PR target/94791: signed pointers should not escape and get
passed across extern call boundaries, since that's an ABI break, but
because existing gcc has this issue we work it around in glibc until
that is resolved. This is compatible with a fixed gcc and it is a nop
on systems without PAuth support. The bug was introduced in gcc-7 with
-msign-return-address=non-leaf|all support which in gcc-9 got renamed
to -mbranch-protection=pac-ret|pac-ret+leaf|standard.
strip_pac uses inline asm instead of __builtin_aarch64_xpaclri since
that is not a documented api and not available in all supported gccs.
commit fe35e074f38bfc3705374939138f936d64e88a22
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 29 11:49:20 2020 +0100
aarch64: Add pac-ret support to assembly files
Use return address signing in assembly files for functions that save
LR when pac-ret is enabled in the compiler.
The GNU property note for PAC-RET is not meaningful to the dynamic
linker so it is not strictly required, but it may be used to track
the security property of binaries. (The PAC-RET property is only set
if BTI is set too because BTI implies working GNU property support.)
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit e5a6ef585542c2b1ef7663a062630995a2a7231d
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Thu May 7 18:30:12 2020 +0100
aarch64: configure check for pac-ret code generation
Return address signing requires unwinder support, which is
present in libgcc since >=gcc-7, however due to bugs the
support may be broken in <gcc-10 (and similarly there may
be issues in custom unwinders), so pac-ret is not always
safe to use. So in assembly code glibc should only use
pac-ret if the compiler uses it too. Unfortunately there
is no predefined feature macro for it set by the compiler
so pac-ret is inferred from the code generation.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
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.
commit 2d49a4ff18f58ada3ed426ffe92ad4ca4a6af272
Author: Sudakshina Das <sudi.das@arm.com>
Date: Mon Jun 22 10:57:20 2020 +0100
aarch64: enable BTI at runtime
Binaries can opt-in to using BTI via an ELF object file marking.
The dynamic linker has to then mprotect the executable segments
with PROT_BTI. In case of static linked executables or in case
of the dynamic linker itself, PROT_BTI protection is done by the
operating system.
On AArch64 glibc uses PT_GNU_PROPERTY instead of PT_NOTE to check
the properties of a binary because PT_NOTE can be unreliable with
old linkers (old linkers just append the notes of input objects
together and add them to the output without checking them for
consistency which means multiple incompatible GNU property notes
can be present in PT_NOTE).
BTI property is handled in the loader even if glibc is not built
with BTI support, so in theory user code can be BTI protected
independently of glibc. In practice though user binaries are not
marked with the BTI property if glibc has no support because the
static linked libc objects (crt files, libc_nonshared.a) are
unmarked.
This patch relies on Linux userspace API that is not yet in a
linux release but in v5.8-rc1 so scheduled to be in Linux 5.8.
Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
commit 703df8e40ece08466090e755cd391f0e1e56fb9e
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Mon Jun 22 10:56:38 2020 +0100
rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handling
Add generic code to handle PT_GNU_PROPERTY notes. Invalid
content is ignored, _dl_process_pt_gnu_property is always called
after PT_LOAD segments are mapped and it has no failure modes.
Currently only one NT_GNU_PROPERTY_TYPE_0 note is handled, which
contains target specific properties: the _dl_process_gnu_property
hook is called for each property.
The old _dl_process_pt_note and _rtld_process_pt_note differ in how
the program header is read. The old _dl_process_pt_note is called
before PT_LOAD segments are mapped and _rtld_process_pt_note is called
after PT_LOAD segments are mapped. The old _rtld_process_pt_note is
removed and _dl_process_pt_note is always called after PT_LOAD
segments are mapped and now it has no failure modes.
The program headers are scanned backwards so that PT_NOTE can be
skipped if PT_GNU_PROPERTY exists.
Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>
commit 61533cce8675be5a47148caf64a64c6315a4206d
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Tue Mar 31 17:32:14 2020 +0100
aarch64: fix RTLD_START for BTI
Tailcalls must use x16 or x17 for the indirect branch instruction
to be compatible with code that uses BTI c at function entries.
(Other forms of indirect branches can only land on BTI j.)
Also added a BTI c at the ELF entry point of rtld, this is not
strictly necessary since the kernel does not use indirect branch
to get there, but it seems safest once building glibc itself with
BTI is supported.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit 90584dd4ca8871295e45d7a1fa658252fe581241
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 1 10:31:41 2020 +0100
aarch64: fix swapcontext for BTI
setcontext returns to the specified context via an indirect jump,
so there should be a BTI j.
In case of getcontext (and all other returns_twice functions) the
compiler adds BTI j at the call site, but swapcontext is a normal
c call that is currently not handled specially by the compiler.
So we change swapcontext such that the saved context returns to a
local address that has BTI j and then swapcontext returns to the
caller via a normal RET. For this we save the original return
address in the slot for x1 of the context because x1 need not be
preserved by swapcontext but it is restored when the context saved
by swapcontext is resumed.
The alternative fix (which is done on x86) would make swapcontext
special in the compiler so BTI j is emitted at call sites, on
x86 there is an indirect_return attribute for this, on AArch64
we would have to use returns_twice. It was decided against because
such fix may need user code updates: the attribute has to be added
when swapcontext is called via a function pointer and it breaks
always_inline functions with swapcontext.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit 80723d093c60fee1f9e96c37e1102a011fa5c15c
Author: Sudakshina Das <sudi.das@arm.com>
Date: Tue Mar 17 15:44:18 2020 +0000
aarch64: Add BTI support to assembly files
To enable building glibc with branch protection, assembly code
needs BTI landing pads and ELF object file markings in the form
of a GNU property note.
The landing pads are unconditionally added to all functions that
may be indirectly called. When the code segment is not mapped
with PROT_BTI these instructions are nops. They are kept in the
code when BTI is not supported so that the layout of performance
critical code is unchanged across configurations.
The GNU property notes are only added when there is support for
BTI in the toolchain, because old binutils does not handle the
notes right. (Does not know how to merge them nor to put them in
PT_GNU_PROPERTY segment instead of PT_NOTE, and some versions
of binutils emit warnings about the unknown GNU property. In
such cases the produced libc binaries would not have valid
ELF marking so BTI would not be enabled.)
Note: functions using ENTRY or ENTRY_ALIGN now start with an
additional BTI c, so alignment of the following code changes,
but ENTRY_ALIGN_AND_PAD was fixed so there is no change to the
existing code layout. Some string functions may need to be
tuned for optimal performance after this commit.
Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit f76a919e8900dfa93eb5ad828d532c8b6ffa3767
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 1 09:52:37 2020 +0100
aarch64: Rename place holder .S files to .c
The compiler can add required elf markings based on CFLAGS
but the assembler cannot, so using C code for empty files
creates less of a maintenance problem.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit cf32244b586222b0ab68e3b49d7394c35d00dea5
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed May 6 20:22:16 2020 +0100
aarch64: configure test for BTI support
Check BTI support in the compiler and linker. The check also
requires READELF that understands the BTI GNU property note.
It is expected to succeed with gcc >=gcc-9 configured with
--enable-standard-branch-protection and binutils >=binutils-2.33.
Note: passing -mbranch-protection=bti in CFLAGS when building glibc
may not be enough to get a glibc that supports BTI because crtbegin*
and crtend* provided by the compiler needs to be BTI compatible too.
commit cf429c3641693277c92b224655601adb2ce39ec4
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 1 16:02:03 2020 +0100
Rewrite abi-note.S in C.
Using C code allows the compiler to add target specific object file
markings based on CFLAGS.
The arm specific abi-note.S is removed and similar object file fix
up will be avoided on AArch64 with standard branch-prtection.
Summary of changes (added commits):
-----------------------------------
1be15b1... aarch64: add NEWS entry about branch protection support
09c1ff2... aarch64: redefine RETURN_ADDRESS to strip PAC
a8014c4... aarch64: fix pac-ret support in _mcount
a87bc4a... aarch64: Add pac-ret support to assembly files
4a42b6f... aarch64: configure check for pac-ret code generation
5273381... aarch64: ensure objects are BTI compatible
582f1a2... aarch64: enable BTI at runtime
09ea243... rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handling
4b3b0a9... aarch64: fix RTLD_START for BTI
83b93ef... aarch64: fix swapcontext for BTI
f26c70e... aarch64: Add BTI support to assembly files
81a0ed9... aarch64: Rename place holder .S files to .c
3492d7d... aarch64: configure test for BTI support
0f47f6f... Rewrite abi-note.S in C.
commit 1be15b1c45e8e90c8746e7103b3151080c49bb76
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Thu Jun 11 18:19:40 2020 +0100
aarch64: add NEWS entry about branch protection support
This is a new security feature that relies on architecture
extensions and needs glibc to be built with a gcc configured
with branch protection.
commit 09c1ff256bbfb8d21474e74ae3bd449239aa32c7
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 15 17:40:45 2020 +0100
aarch64: redefine RETURN_ADDRESS to strip PAC
RETURN_ADDRESS is used at several places in glibc to mean a valid
code address of the call site, but with pac-ret it may contain a
pointer authentication code (PAC), so its definition is adjusted.
This is gcc PR target/94891: __builtin_return_address should not
expose signed pointers to user code where it can cause ABI issues.
In glibc RETURN_ADDRESS is only changed if it is built with pac-ret.
There is no detection for the specific gcc issue because it is
hard to test and the additional xpac does not cause problems.
commit a8014c48c1a2a0398e49b04a08962355c7dcbb11
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed May 13 12:10:13 2020 +0100
aarch64: fix pac-ret support in _mcount
Currently gcc -pg -mbranch-protection=pac-ret passes signed return
address to _mcount, so _mcount now has to always strip pac from the
frompc since that's from user code that may be built with pac-ret.
This is gcc PR target/94791: signed pointers should not escape and get
passed across extern call boundaries, since that's an ABI break, but
because existing gcc has this issue we work it around in glibc until
that is resolved. This is compatible with a fixed gcc and it is a nop
on systems without PAuth support. The bug was introduced in gcc-7 with
-msign-return-address=non-leaf|all support which in gcc-9 got renamed
to -mbranch-protection=pac-ret|pac-ret+leaf|standard.
strip_pac uses inline asm instead of __builtin_aarch64_xpaclri since
that is not a documented api and not available in all supported gccs.
commit a87bc4ad93ba09f35adb9284fc932627e3b6990d
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 29 11:49:20 2020 +0100
aarch64: Add pac-ret support to assembly files
Use return address signing in assembly files for functions that save
LR when pac-ret is enabled in the compiler.
The GNU property note for PAC-RET is not meaningful to the dynamic
linker so it is not strictly required, but it may be used to track
the security property of binaries. (The PAC-RET property is only set
if BTI is set too because BTI implies working GNU property support.)
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit 4a42b6f00778f009349c08ead8603d6d76e9928b
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Thu May 7 18:30:12 2020 +0100
aarch64: configure check for pac-ret code generation
Return address signing requires unwinder support, which is
present in libgcc since >=gcc-7, however due to bugs the
support may be broken in <gcc-10 (and similarly there may
be issues in custom unwinders), so pac-ret is not always
safe to use. So in assembly code glibc should only use
pac-ret if the compiler uses it too. Unfortunately there
is no predefined feature macro for it set by the compiler
so pac-ret is inferred from the code generation.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
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.
commit 582f1a25ace0bffb2e8fbec9a85d3fcaf55b84e5
Author: Sudakshina Das <sudi.das@arm.com>
Date: Mon Jun 22 10:57:20 2020 +0100
aarch64: enable BTI at runtime
Binaries can opt-in to using BTI via an ELF object file marking.
The dynamic linker has to then mprotect the executable segments
with PROT_BTI. In case of static linked executables or in case
of the dynamic linker itself, PROT_BTI protection is done by the
operating system.
On AArch64 glibc uses PT_GNU_PROPERTY instead of PT_NOTE to check
the properties of a binary because PT_NOTE can be unreliable with
old linkers (old linkers just append the notes of input objects
together and add them to the output without checking them for
consistency which means multiple incompatible GNU property notes
can be present in PT_NOTE).
BTI property is handled in the loader even if glibc is not built
with BTI support, so in theory user code can be BTI protected
independently of glibc. In practice though user binaries are not
marked with the BTI property if glibc has no support because the
static linked libc objects (crt files, libc_nonshared.a) are
unmarked.
This patch relies on Linux userspace API that is not yet in a
linux release but in v5.8-rc1 so scheduled to be in Linux 5.8.
Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
commit 09ea243d4b4a9f1d644e6445fcdd27185c78e44d
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Mon Jun 22 10:56:38 2020 +0100
rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handling
Add generic code to handle PT_GNU_PROPERTY notes. Invalid
content is ignored, _dl_process_pt_gnu_property is always called
after PT_LOAD segments are mapped and it has no failure modes.
Currently only one NT_GNU_PROPERTY_TYPE_0 note is handled, which
contains target specific properties: the _dl_process_gnu_property
hook is called for each property.
The old _dl_process_pt_note and _rtld_process_pt_note differ in how
the program header is read. The old _dl_process_pt_note is called
before PT_LOAD segments are mapped and _rtld_process_pt_note is called
after PT_LOAD segments are mapped. The old _rtld_process_pt_note is
removed and _dl_process_pt_note is always called after PT_LOAD
segments are mapped and now it has no failure modes.
The program headers are scanned backwards so that PT_NOTE can be
skipped if PT_GNU_PROPERTY exists.
Co-Authored-By: H.J. Lu <hjl.tools@gmail.com>
commit 4b3b0a983285237dbe9cce7a45f722b66a507c1d
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Tue Mar 31 17:32:14 2020 +0100
aarch64: fix RTLD_START for BTI
Tailcalls must use x16 or x17 for the indirect branch instruction
to be compatible with code that uses BTI c at function entries.
(Other forms of indirect branches can only land on BTI j.)
Also added a BTI c at the ELF entry point of rtld, this is not
strictly necessary since the kernel does not use indirect branch
to get there, but it seems safest once building glibc itself with
BTI is supported.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit 83b93efe96bd800d3866ac3c79a91f822999ea03
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 1 10:31:41 2020 +0100
aarch64: fix swapcontext for BTI
setcontext returns to the specified context via an indirect jump,
so there should be a BTI j.
In case of getcontext (and all other returns_twice functions) the
compiler adds BTI j at the call site, but swapcontext is a normal
c call that is currently not handled specially by the compiler.
So we change swapcontext such that the saved context returns to a
local address that has BTI j and then swapcontext returns to the
caller via a normal RET. For this we save the original return
address in the slot for x1 of the context because x1 need not be
preserved by swapcontext but it is restored when the context saved
by swapcontext is resumed.
The alternative fix (which is done on x86) would make swapcontext
special in the compiler so BTI j is emitted at call sites, on
x86 there is an indirect_return attribute for this, on AArch64
we would have to use returns_twice. It was decided against because
such fix may need user code updates: the attribute has to be added
when swapcontext is called via a function pointer and it breaks
always_inline functions with swapcontext.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit f26c70e602b52dd05f167c93f44e8efbceac7fb9
Author: Sudakshina Das <sudi.das@arm.com>
Date: Tue Mar 17 15:44:18 2020 +0000
aarch64: Add BTI support to assembly files
To enable building glibc with branch protection, assembly code
needs BTI landing pads and ELF object file markings in the form
of a GNU property note.
The landing pads are unconditionally added to all functions that
may be indirectly called. When the code segment is not mapped
with PROT_BTI these instructions are nops. They are kept in the
code when BTI is not supported so that the layout of performance
critical code is unchanged across configurations.
The GNU property notes are only added when there is support for
BTI in the toolchain, because old binutils does not handle the
notes right. (Does not know how to merge them nor to put them in
PT_GNU_PROPERTY segment instead of PT_NOTE, and some versions
of binutils emit warnings about the unknown GNU property. In
such cases the produced libc binaries would not have valid
ELF marking so BTI would not be enabled.)
Note: functions using ENTRY or ENTRY_ALIGN now start with an
additional BTI c, so alignment of the following code changes,
but ENTRY_ALIGN_AND_PAD was fixed so there is no change to the
existing code layout. Some string functions may need to be
tuned for optimal performance after this commit.
Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit 81a0ed9464d3f7f9cb444ed1f76475f3004a01f8
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 1 09:52:37 2020 +0100
aarch64: Rename place holder .S files to .c
The compiler can add required elf markings based on CFLAGS
but the assembler cannot, so using C code for empty files
creates less of a maintenance problem.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
commit 3492d7d40821a9375baae96d053d3791f30d83f8
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed May 6 20:22:16 2020 +0100
aarch64: configure test for BTI support
Check BTI support in the compiler and linker. The check also
requires READELF that understands the BTI GNU property note.
It is expected to succeed with gcc >=gcc-9 configured with
--enable-standard-branch-protection and binutils >=binutils-2.33.
Note: passing -mbranch-protection=bti in CFLAGS when building glibc
may not be enough to get a glibc that supports BTI because crtbegin*
and crtend* provided by the compiler needs to be BTI compatible too.
commit 0f47f6f311594ec1ea44526e20e5f9986fa5a6ba
Author: Szabolcs Nagy <szabolcs.nagy@arm.com>
Date: Wed Apr 1 16:02:03 2020 +0100
Rewrite abi-note.S in C.
Using C code allows the compiler to add target specific object file
markings based on CFLAGS.
The arm specific abi-note.S is removed and similar object file fix
up will be avoided on AArch64 with standard branch protection.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2020-07-02 8:38 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-02 8:38 [glibc/nsz/pacbti-v6] (14 commits) aarch64: add NEWS entry about branch protection support 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).