Skip to content

[AArch64] Add support for pointer authentication relocations#801

Open
nezetic wants to merge 1 commit intoqualcomm:mainfrom
nezetic:auth-reloc-support
Open

[AArch64] Add support for pointer authentication relocations#801
nezetic wants to merge 1 commit intoqualcomm:mainfrom
nezetic:auth-reloc-support

Conversation

@nezetic
Copy link
Contributor

@nezetic nezetic commented Feb 10, 2026

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.

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>
@svs-quic
Copy link
Contributor

@pzhengqc might be a better suited to review this.

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 ||
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

@nezetic nezetic Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants