Open MaskRay opened 6 months ago
Are there figures on how many regular relative relocations are transformed into R_AARCH64_AUTH_RELATIVE under PAuthABI?
The 32b limit was chosen on the basis that in the vast majority of cases (small code model, position independent code) the addend is going to be within the 0..2^32 range. So I would say that in a typical userspace, pretty much every relocation is going to use this.
I agree that in the majority of cases linkers don't need to move a relocation from .relr.auth.dyn
to .rela.dyn
.
The question is do we need this RELR variant?
If we use CREL (while size(.crel.dyn)/size(.relr.dyn)
may be 3.5x, size(.crel.dyn)/size(.o)
is just 0.3%), supporting AUTH relative will take very few lines in https://github.com/MaskRay/llvm-project/blob/demo-crel/lld/ELF/SyntheticSections.cpp around CrelSection<uint>::updateAllocSize
, and the code will be centralized in one place.
Got it, I misread your earlier message and thought you were asking about .rela.dyn
-> .relr.auth.dyn
rather than R_AARCH64_ABS64
-> R_AARCH64_AUTH_ABS64
. Let me see if I can collect those numbers for AOSP.
I built AOSP with PAuth ABI disabled and enabled for the Cuttlefish (i.e. emulator) arm64 target and ran the following commands from the symbols
directory of the build directory, which contains unstripped versions of all built binaries shipped on the device.
$ llvm-readelf -rW (find -type f) | grep 000000000000e20| wc -l
524144
$ llvm-readelf -rW (find -type f) | grep R_AARCH64_RELATIVE| wc -l
725136
So around 40% of R_AARCH64_RELATIVE
relocations become R_AARCH64_AUTH_RELATIVE
.
Also, the total size of all SHT_RELR
sections in a tree of binaries built with PAuth ABI disabled is 460824 bytes and with PAuth ABI enabled is 307032 bytes. So we can estimate that the total DT_AARCH64_AUTH_RELR
size if it were implemented would be around 150KB. Assuming a 3.5x ratio for CREL vs RELR that would mean it would cost 375KB in the shipped image not to have DT_AARCH64_AUTH_RELR
(i.e. 0.04% of the total image size of 1.1GB), but I would expect the actual ratio to be higher than for DT_RELR
since each relocation contains more information.
Is there any need for any specification updates at the moment? My intent behind DT_AARCH64_AUTH_RELR
was to match the existing ELF RELR as closely as possible on the grounds that it would be fairly simple to implement in existing loaders. Their use is not meant to be required by the base standard, although a platform that implements the spec may require it.
I can see that if CREL is standardised and accepted then it would make sense to support that too, although I'm reluctant to take out DT_AARCH64_AUTH_RELR
unless all implementors are happy to switch to CREL.
Recently, I have proposed a compact relocation format CREL at https://groups.google.com/g/generic-abi/c/yb0rjw56ORw/m/eiBcYxSfAQAJ (previously named RELLEB). (https://github.com/MaskRay/llvm-project/tree/demo-crel adds CREL support to clang/lld/LLVM binary utilities.
clang -fuse-ld=lld -mcrel a.c
)CREL shines for GLOB_DAT/JUMP_SLOT and absolute relocations, often requiring mere 2 bytes (offset adjustment and symbol index update). While it might not be as effective for relative relocations compared to RELR, I'm interested in a quantitative evaluation of DT_AARCH64_AUTH_RELR (a RELR variant).
DT_AARCH64_AUTH_RELR requires the addend to be 32-bit and the linker support requires moving addend-out-of-range relocations to
.rela.dyn
, complicating the design.Are there figures on how many regular relative relocations are transformed into R_AARCH64_AUTH_RELATIVE under PAuthABI? (Open-source rtld/libc might favor a smaller set of supported relocation formats. CREL is tackling with a very difficult problem, but it has the potential to phase out REL/RELA, decreasing complexity for future new architectures.)
I am using a Release build of clang-16 as an example. RELR is much better than CREL in compacting relative relocations.
In a release build of Clang 16, using -z crel resulted in a .crel.dyn section size of only 1.0% of the file size. Notably, enabling implicit addends with -z crel -z rel further reduced the size to just 0.3%. While DT_AARCH64_AUTH_RELR will achieve a noticeable smaller relocation size if most relative relocations are encoded with it, the advantage seems less significant considering CREL's already compact size.
A CREL with addend implementation for relative relocations unnecessarily encode the addend in the relocation.
-z crel -z rel
switches to implicit addends:My blog post provides more description about implicit addends around https://maskray.me/blog/2024-03-09-a-compact-relocation-format-for-elf#:~:text=DT_AARCH64_AUTH_RELR