[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251113200633.833127-1-bill.roberts@arm.com>
Date: Thu, 13 Nov 2025 13:44:25 -0600
From: Bill Roberts <bill.roberts@....com>
To: musl@...ts.openwall.com
Cc: Bill Roberts <bill.roberts@....com>
Subject: [PATCH 0/3] RFC: Enable PAC and BTI for aarch64
Hello,
I am floating a proposal to add PAC (Pointer Authentication) and BTI
(Branch Target Identification) support for MUSL on AArch64 targets.
For anyone looking for a quick overview of what this means for software
developers, this blog post provides a good summary:
https://developer.arm.com/community/arm-community-blogs/b/architectures-
and-processors-blog/posts/enabling-pac-and-bti-on-aarch64
(Full disclosure: I may be a bit biased there.)
Summary below, but the git commit messages and comments should clarify
anything not immediately obvious (hopefully).
MUSL is fortunately well-structured, so adding this support is not too
complex. I wrote the assembly assuming the hardware supports PAC and BTI,
and then used awk to post-process it out when needed. This approach seemed
simpler than tracking stack usage, identifying jump vs. call targets, and
trying to add the features afterward within awk.
When writing assembly, it is easier to assume the feature is supported.
By doing so, it keeps the relevant instructions visible rather than
debugging an awk script that might surprise you or be inserting extra
instructions unexpectedly.
For BTI, there are two aspects to consider. The first is the loader, which
needs to mmap/mprotect with PROT_BTI. The second is the addition of BTI
instructions and GNU note annotations. These two parts are independent of
each other.
For PAC, it is mainly a matter of enabling the instructions and adding the
GNU Notes annotations.
-- Possible Alternative Implementation --
Another way this could be done is to add the instructions unconditionally.
i.e do not remove them. One nice property of these extensions is that binaries
can include PAC and BTI instructions unconditionally. On hardware that does
not support these features, the hint-space instructions effectively NOP,
maintaining ABI and backward compatibility. This means we do not need to build separate
variants or introduce conditional support in most cases. The only thing
to consider would be switching PAC keys from A to B.
Thanks,
Bill
Bill Roberts (3):
dso/aarch64: add PROT_BTI support for mem maps
Makefile: support awk processing of .S files
aarch64: enable PAC and BTI instruction support in musl build
Makefile | 25 ++++--
arch/aarch64/crt_arch.h | 3 +
configure | 14 +++-
crt/aarch64/crti.s | 2 +
crt/aarch64/crtn.s | 2 +
include/elf.h | 2 +
ldso/dynlink.c | 50 ++++++++++--
src/fenv/aarch64/fenv.s | 7 ++
src/ldso/aarch64/arch_ldso_hook.c | 90 ++++++++++++++++++++++
src/ldso/aarch64/arch_ldso_hook.h | 21 +++++
src/ldso/aarch64/tlsdesc.s | 2 +
src/process/aarch64/vfork.s | 1 +
src/setjmp/aarch64/longjmp.s | 1 +
src/setjmp/aarch64/setjmp.s | 1 +
src/signal/aarch64/restore.s | 1 +
src/signal/aarch64/sigsetjmp.s | 2 +
src/string/aarch64/memcpy.S | 1 +
src/string/aarch64/memset.S | 1 +
src/thread/aarch64/__unmapself.s | 1 +
src/thread/aarch64/clone.s | 1 +
src/thread/aarch64/syscall_cp.s | 1 +
tools/pac-bti-aarch64.awk | 122 ++++++++++++++++++++++++++++++
22 files changed, 336 insertions(+), 15 deletions(-)
create mode 100644 src/ldso/aarch64/arch_ldso_hook.c
create mode 100644 src/ldso/aarch64/arch_ldso_hook.h
create mode 100644 tools/pac-bti-aarch64.awk
--
2.51.0
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
