[AArch64] Add support for pointer authentication relocations by nezetic · Pull Request #801 · qualcomm/eld

nezetic · 2026-02-10T15:04:03Z

Implements basic PAuth support for AArch64 following the PAuth ABI Extension specification (2025Q1):
https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst

Adds:

R_AARCH64_AUTH_ABS64 (0x244): authenticated absolute relocations
R_AARCH64_AUTH_RELATIVE (0x411): authenticated relative relocations

Testing:
Covers PIE/non-PIE/static executables, as well as various corner cases from the spec like undefined weak references, COPY relocations and non-allocating sections.

Not included:
GOT/PLT signing, additional AUTH relocation types (future work).

Notes:
I changed the way GNULDBackend::recordRelativeReloc store relative relocations. The original map is only iterated once (in a linear way), but reversing the key / values allows to implement an efficient GNULDBackend::findRelativeReloc.

No changes to existing non-AUTH relocation behavior.

svs-quic · 2026-02-11T04:32:51Z

@pzhengqc might be a better suited to review this.

quic-areg · 2026-02-11T21:22:43Z

lib/Target/AArch64/AArch64ELFDynamic.cpp

  uint32_t relaCount = 0;
  for (auto &R : m_Backend.getRelaDyn()->getRelocations()) {
-    if (R->type() == llvm::ELF::R_AARCH64_RELATIVE)
+    if (R->type() == llvm::ELF::R_AARCH64_RELATIVE ||


I think this may lead to a potentially wrong DT_RELACOUNT value with eld (lld does not count AARCH64_AUTH_RELATIVE here).

My understanding if that DT_RELACOUNT represents the number of relative relocations in .rela.dyn. AARCH64_AUTH_RELATIVE relocations will end up in this section, so they must be counted.

Relocation section '.rela.dyn' at offset 0x1e8 contains 11 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
0000000000001130 0000000000000411 R_AARCH64_AUTH_RELATIVE 341
0000000000001138 0000000000000411 R_AARCH64_AUTH_RELATIVE 1132

It's important to note LLD implement a very tedious (and optional) Relocation Compression (section 11) , that is not in the scope of this PR.

I did not perform a 1:1 comparaison with LLD, but made sure ELD is passing similar tests.

quic-seaswara · 2026-02-18T20:24:06Z

@efriedma-quic can you please review this change ?

efriedma-quic · 2026-02-18T21:32:36Z

lib/Target/AArch64/AArch64LDBackend.cpp

+  auto Entry = m_RelativeRelocMap.find(pReloc);
+  if (Entry == m_RelativeRelocMap.end())
+    return nullptr;
+  return Entry->second;


Suggested change

auto Entry = m_RelativeRelocMap.find(pReloc);

if (Entry == m_RelativeRelocMap.end())

return nullptr;

return Entry->second;

return m_RelativeRelocMap.lookup(pReloc);

Updated the code 👍

efriedma-quic · 2026-02-18T22:01:05Z

lib/Target/AArch64/AArch64RelocationFunctions.h

      ValueType(0x23d,                                                         \
                MappedType(&unsupport,                                         \
                           "R_AARCH64_TLSLE_LDST128_DTPREL_LO12_NC", 32)),     \
+      ValueType(0x244, MappedType(&abs, "R_AARCH64_AUTH_ABS64", 64)),          \


Can we arrange this header in the same order as llvm/BinaryFormat/ELFRelocs/AArch64.def, to make future updates easier?

I updated the header based on AArch64.def, adding all AUTH relocations in the same order

efriedma-quic · 2026-02-18T22:14:05Z

lib/Target/AArch64/AArch64Relocator.cpp

    // a dynamic relocations with RELATIVE type to this location is needed.
    // Reserve an entry in .rel.dyn
-    if (config().isCodeIndep()) {
+    if (config().isCodeIndep() || isAuthReloc(pReloc)) {


Using isAuthReloc() instead of just pReloc.type() == llvm::ELF::R_AARCH64_AUTH_ABS64 feels a little strange.

Indeed, I simplified the code a bit, testing only with R_AARCH64_AUTH_ABS64 where I'm only matching this one (abs function and relocation scan switch cases).

efriedma-quic · 2026-02-18T22:19:20Z

test/AArch64/standalone/Relocations/PAuthReloc.s

+# STATIC-NEXT:       {{0x[0-9A-F]+}} R_AARCH64_AUTH_RELATIVE - {{0x[0-9A-F]+}}
+# STATIC-NEXT: }
+
+# Test PAuth relocations with static executable (without PIE)


In a static executable, what code actually processes the rela.dyn section?

In the case of a baremetal binary (a firmware), a custom dynamic linker (as it's already the case for things like TZ).

efriedma-quic · 2026-02-18T22:21:53Z

test/AArch64/standalone/Relocations/PAuthReloc.s

+foo:
+
+#--- main.s
+.section .test, "aw"


Maybe worth adding a test to show what happens if you try to use R_AARCH64_AUTH_ABS64 in a readonly section?

I added a few relocations in a read-only section in the tests.

As far I understand the specifications, there are no restrictions regarding read-only sections.

The spec might not say anything, but eld defaults to -z text, which should forbid such relocations?

Implements basic PAuth support for AArch64 following the PAuth ABI Extension specification (2025Q1): https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst **Adds:** - R_AARCH64_AUTH_ABS64 (0x244): authenticated absolute relocations - R_AARCH64_AUTH_RELATIVE (0x411): authenticated relative relocations **Testing:** Covers PIE/non-PIE/static executables, as well as various corner cases from the spec like undefined weak references, COPY relocations and non-allocating sections. **Not included:** GOT/PLT signing, additional AUTH relocation types (future work). **Notes:** I changed the way *GNULDBackend::recordRelativeReloc* store relative relocations. The original map is only iterated once (in a linear way), but reversing the key / values allows to implement an efficient *GNULDBackend::findRelativeReloc*. No changes to existing non-AUTH relocation behavior. Signed-off-by: Cedric Tessier <ctessier@qti.qualcomm.com>

nezetic force-pushed the auth-reloc-support branch 2 times, most recently from 2d93aa4 to 7c37e18 Compare February 10, 2026 15:12

quic-seaswara requested review from apazos, quic-areg, quic-seaswara and svs-quic February 10, 2026 21:30

quic-areg reviewed Feb 11, 2026

View reviewed changes

nezetic force-pushed the auth-reloc-support branch from 7c37e18 to 4521653 Compare February 17, 2026 18:22

quic-seaswara requested a review from efriedma-quic February 18, 2026 20:23

efriedma-quic reviewed Feb 18, 2026

View reviewed changes

nezetic force-pushed the auth-reloc-support branch from 4521653 to 4bf2f20 Compare February 19, 2026 16:35

nezetic force-pushed the auth-reloc-support branch from 4bf2f20 to 78f7b56 Compare February 19, 2026 16:35

Conversation

nezetic commented Feb 10, 2026

Uh oh!

svs-quic commented Feb 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nezetic Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

quic-seaswara commented Feb 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Comments

nezetic Feb 12, 2026 •

edited

Loading