[AAELF64] BTI and veneers for bare-metal contexts.#322
Merged
smithp35 merged 3 commits intoARM-software:mainfrom Apr 9, 2025
Merged
[AAELF64] BTI and veneers for bare-metal contexts.#322smithp35 merged 3 commits intoARM-software:mainfrom
smithp35 merged 3 commits intoARM-software:mainfrom
Conversation
Range extension veneers in a bare-metal context must not assume a BTI instruction is at the destination. There is documentation in sysvabi64 that states this, but strictly speaking this need not apply to a bare-metal context. Document that linker generated veneers cannot assume a BTI for definitions in the same link unit. Bare-metal systems do not support PLT or iPLT (ifunc) so the requirements surrounding code-generation can stay in the sysvabi64.
Contributor
Author
|
Addresses the indirect veneer part of #321 |
statham-arm
reviewed
Apr 9, 2025
aaelf64/aaelf64.rst
Outdated
|
|
||
| On platforms that do not support dynamic pre-emption of symbols, an unresolved weak reference to a symbol relocated by ``R_<CLS>_CALL26`` shall be treated as a jump to the next instruction (the call becomes a no-op). The behaviour of ``R_<CLS>_JUMP26`` and ``R_<CLS>_PLT32`` in these conditions is not specified by this standard. | ||
|
|
||
| When a static linker uses an indirect branch in a veneer, it may not assume that a destination in the same link unit has a BTI instruction, or BTI compatible instruction, at the destination of the indirect branch. See `SYSVABI64`_ for additional requirements on code-generators and PLT sequences. |
Contributor
There was a problem hiding this comment.
The sentiment LGTM. Some thoughts about clarification:
- possibly not all readers know what a BTI is, so does this need to be prefixed with some kind of condition "When BTI branch protection is in use, ..." and a link of some kind so they can at least find out that it's a CPU feature they aren't using?
- this only says what linkers can't do, and not what they should do instead. Do you need to spell out in full "... and so if the linker needs to add a long-branch thunk using an indirect call instruction, it must insert a landing pad containing a BTI which branches to the destination directly"?
But maybe I'm being too cautious, and the typical reader of this document who isn't using BTI will at least recognise the name as "some CPU feature I don't need to worry about", and one who is will be able to figure out for themself what they'd have to do in the linker to satisfy this requirement?
Contributor
Author
There was a problem hiding this comment.
Thanks for the comments. I've had another go.
I put BTI in the terms and definitions section at the top, and have given more of a suggestion about what linker's should do.
* Added a description of BTI to the terms. * Stated requirements for linker veneers in terms of what a linker should do. * Addend entry to change history.
statham-arm
approved these changes
Apr 9, 2025
Contributor
statham-arm
left a comment
statham-arm
left a comment
There was a problem hiding this comment.
Thanks, the changes LGTM (with one tiny grammar nit).
aaelf64/aaelf64.rst
Outdated
|
|
||
| On platforms that do not support dynamic pre-emption of symbols, an unresolved weak reference to a symbol relocated by ``R_<CLS>_CALL26`` shall be treated as a jump to the next instruction (the call becomes a no-op). The behaviour of ``R_<CLS>_JUMP26`` and ``R_<CLS>_PLT32`` in these conditions is not specified by this standard. | ||
|
|
||
| In a link-unit that is intended to be used when BTI guarded pages are enable, veneers created by the static linker that use an indirect branch must target a BTI instruction or a BTI compatible instruction. If the destination of the veneer is in the same link unit and does not have a BTI or BTI compatible instruction, the static linker must generate an additional veneer that has a BTI instruction followed by a transfer of control to the destination that does not use an indirect branch. See `SYSVABI64`_ for additional requirements on code-generators and PLT sequences. |
Contributor
There was a problem hiding this comment.
nit: "are enable" → "are enabled"
Contributor
Author
There was a problem hiding this comment.
ACK, thanks for spotting.
enable -> enabled.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Range extension veneers in a bare-metal context must not assume a BTI instruction is at the destination.
There is documentation in sysvabi64 that states this, but strictly speaking this need not apply to a bare-metal context. Document that linker generated veneers cannot assume a BTI for definitions in the same link unit.
Bare-metal systems do not support PLT or iPLT (ifunc) so the requirements surrounding code-generation can stay in the sysvabi64.