[PAUTHABIELF64] Introduce an alternative relocation encoding#398
[PAUTHABIELF64] Introduce an alternative relocation encoding#398smithp35 wants to merge 2 commits into
Conversation
Embedded systems may require dynamic relocations to be idempotent as they need to initialize, then copy themselves to a new address for ASLR purposes, then resign. As idempotent relocations are an ABI break for existing platforms and have additional limitations over the current encoding this is written as an Appendix for comment. Platforms are expected to choose one form of encoding for their relocations. It is possible to transform the existing encoding into the new one with a post-link tool, however the alternative format could be implemented directly in a static linker. If there is a static-linker implementation, my current thought is that it would be best to encode the desire for idempotent relocations via the signing-schema in the object file. That way it is harder to get incompatibilites arising from someone forgetting a command-line options.
|
This has been created as a result of Discord Thread https://discord.com/channels/636084430946959380/1133112394701348895/1513540731615314050 which contains more background for the use case. |
|
I have read through this PR and having this workaround described in the PAuth ABI extension document would work for us because we would have an authoritative reference to justify our implementation. Another possibility is to copy the signature schema from the "place" into the addend field on the first relocation round, assuming the added has at most 32 bits. I would just like to raise the issue of finding a "proper" solution to store additional relocation metadata without sacrificing neither addend space nor the idempotency guarantee given here: https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#idempotency. I can only think of very painful solutions:
In addition, we would also need something that ensures the combination of different extensions, like PAuth and Memtag, does not create conflicts. Even storing everything in the "place", as it is now, there is no 32 bits limit on the tag offset in the Memtag ABI extension, so it could technically overflow into the PAuth schema if the two are combined. |
| +--------------------+------------------------------+------------------------------------+ | ||
| | Relocation code | Name | Operation | | ||
| +====================+==============================+====================================+ | ||
| | 0x244 (580) | R\_AARCH64\_AUTH\_ABS64 | SIGN(S + ADDEND(A), SCHEMA(A) | |
There was a problem hiding this comment.
typo: Missing ) in SIGN(S + ADDEND(A)
There was a problem hiding this comment.
Thank you. Now fixed.
3 participants
Embedded systems may require dynamic relocations to be idempotent as they need to initialize, then copy themselves to a new address for ASLR purposes, then resign.
As idempotent relocations are an ABI break for existing platforms and have additional limitations over the current encoding this is written as an Appendix for comment.
Platforms are expected to choose one form of encoding for their relocations.
It is possible to transform the existing encoding into the new one with a post-link tool, however the alternative format could be implemented directly in a static linker.
If there is a static-linker implementation, my current thought is that it would be best to encode the desire for idempotent relocations via the signing-schema in the object file. That way it is harder to get incompatibilites arising from someone forgetting a command-line options.