Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PAUTHABIELF64] Add R_AARCH64_AUTH_GOT_ADR_PREL_LO21 relocation #259

Merged
merged 1 commit into from
Jul 2, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 25 additions & 4 deletions pauthabielf64/pauthabielf64.rst
Original file line number Diff line number Diff line change
Expand Up @@ -1069,7 +1069,7 @@ GOT entry as the modifier. The static linker must encode the signing
schema into the GOT slot. AUTH variant dynamic relocations must be
used for signed GOT entries.

Example Code to access a signed GOT entry
Example Code to access a signed GOT entry with the small code model:

.. code-block:: asm
Expand All @@ -1082,6 +1082,18 @@ Example Code to access a signed GOT entry
In the example the :got_auth: and :got_auth_lo12: operators result in
AUTH variant GOT generating relocations being used.

Example Code to access a signed GOT entry with the tiny code model:

.. code-block:: asm
adr x8, :got_auth: symbol
ldr x0, [x8]
// Authenticate to get unsigned pointer
autia x0, x8
Compared to the tiny code model without pointer authentication an
additonal adr is required to get the address of the GOT entry.
Comment on lines +1094 to +1095
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure I am following here - all PLT sequences as currently defined(1) must compute the address of the GOT entry for the dynamic linker. So the ADR is required even without PAUTH, and it would be worth having the equivalent relocation if it doesn't already exist (given that just having PC-relative LDR won't work).

(1) It is possible to define PLT sequences that compute the address of the GOT entry in a different way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is intended for something like:

int x;
int* f(void) {
  return &x;
}

Which with the tiny code-model is

f:
        ldr     x0, :got:x
        ret

There's no need for the adr, in the non PAuth case. In the PAuth case the address is needed for authentication.

All the current linker PLT implementations use the small code-model so they use adrp. I take the point that we could have a tiny PLT sequence, off the top of my head something like:

adr x16, <address of .got.plt entry>
ldr x17, [x16]
br x17

Which would need a non-Auth equivalent relocation like R_AARCH64_GOT_ADR_PREL_LO21. Although as the linker generates the .plt and the .got.plt so it could just implement the calculation without a relocation directive.

Is there a need for something like R_AARCH64_GOT_ADR_PREL_LO21 in user code?

Copy link
Contributor

Choose a reason for hiding this comment

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

You're right, there doesn't seem a case for user code, so if linkers use internal relocations then there is no need to add one.


AUTH variant GOT Generating Relocations
---------------------------------------

Expand Down Expand Up @@ -1157,6 +1169,11 @@ The GOT entries must be relocated by AUTH variant dynamic relocations.
| | | | value to bits [11:0] of |
| | | | X. No overflow check. |
+-------------+----------------------------------------+----------------------------------+--------------------------+
| 0x811D | R\AARCH64\_AUTH\_GOT\_ADR\_PREL\_LO21 | G(ENCD(GDAT(S + A))) - P | Set the immediate |
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove the +A

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd prefer to keep the +A until we've come to a conclusion about #217 and then I'll submit a patch to remove all of the addends from GOT generating relocations at once.

Reminds me to ping for responses to an internal proposal on #217

| | | | value to bits[20:0] of X;|
| | | | check that -2 :sup:`20` |
| | | | <= 2 :sup: `20` |
+-------------+----------------------------------------+----------------------------------+--------------------------+
.. raw:: pdf

PageBreak
Expand All @@ -1170,9 +1187,13 @@ is the PAuth ABI equivalent of ``R_AARCH64_RELATIVE``. The underlying
calculation performed by the dynamic linker is the same, the only
difference is that the resulting pointer is signed. The dynamic linker
reads the signing schema from the contents of the place of the dynamic
relocation. The ``R_AARCH64_AUTH_GOT_ADD_LO12_NC`` relocation is an
addition for the PAuth ABI and has no equivalent in (AAELF64_). It is
used with the ``:got_auth_lo12:`` operator on an add instruction.
relocation.

The ``R_AARCH64_AUTH_GOT_ADD_LO12_NC`` relocation is an addition for
the PAuth ABI and has no equivalent in (AAELF64_). It is

The ``R_AARCH64_AUTH_GOT_ADR_PREL_LO21`` relocation is used with the
``:got_auth:`` operator on an adr instruction.

.. table:: Additional AUTH Dynamic relocations

Expand Down
Loading