-
Notifications
You must be signed in to change notification settings - Fork 191
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
[Morello] Add the morello descriptor ABI specification. #103
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an undocumented implicit requirement that CCTLR.ADRDPB be 1 so that C28 is used, no?
How does all of this interact with TLS so you get per-compartment TLS rather than having it shared between copies of the same compartment?
|
||
The Morello Descriptor ABI is a variant of the pure capability ABI which decouples code and | ||
global data addresses, allowing the same code to be used with multiple instances of global data. | ||
This allows compartments to share code in the same address space, while having separata data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This allows compartments to share code in the same address space, while having separata data | |
This allows compartments to share code in the same address space, while having separate data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there is an assumtion that CCTLR.ADRDPB should be set. I'll make that explicit.
Different compartments should have different CTPIDR_ELx/c28/global data so that should produce different values per compartment for the same TLS symbol.
The TLS details are no really covered in this though, I'll send an update for that (there should be a small deviation for purecap when the GD resolver needs to be called).
|
||
__descglobal_sym: | ||
mov c19, c28 | ||
mov c28, c29 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems odd to use c29 here before you specify what's in c29 on entry to the thunk
Capabilities | ||
------------ | ||
|
||
The Descriptor ABI executable capabilities are categorized as Function capabilities and Code capabilities. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Executable" is a bad term to use here; function capabilities do not have execute permission, but load and load capability, so they are not "executable capabilities".
``R_MORELLO_DESC_IRELATIVE`` is used by the linker when transforming ``IFUNC`` s. The | ||
rest are the same as ``R_MORELLO_DESC_RELATIVE`` | ||
|
||
All of the above relocations are against the ``PT_MORELLO_DESC segment``. The fragment encoding |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the above relocations are against the ``PT_MORELLO_DESC segment``. The fragment encoding | |
All of the above relocations are against the ``PT_MORELLO_DESC`` segment. The fragment encoding |
descabi-morello/descabi-morello.rst
Outdated
Each function has an additional entry point (the global entry point) that is used to manage | ||
the value of the Capability Private Data Addressing Register. The global entry point is a thunk | ||
generated by the linker and is used for indirect calls or calls from a different DSO. | ||
The global entry point is located in the same DSO as the associated function. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What section?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure we need a specific section here, as long as it these end up in the pcc bounds.
- The first capability is the value of the Capability Private Data Addressing Register corresponding | ||
to the DSO of the function. The address and base of this capability are the start of the | ||
``.desc.data.rel.ro`` section. This capability is read-only and has the bounds of the | ||
``.desc.data.rel.ro`` section. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And GOT, given 6.1?
|
||
|
||
The value of the Capability Private Data Addressing Register (c28) points to the start of the ``PT_MORELLO_DESC`` | ||
segment, is read-only and can be used to access the ``.desc.data.rel.ro`` and ``.got`` sections. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it need to cover .desc.data.rel.ro
if all descriptors are accessed indirectly via the GOT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently .desc.data.rel.ro contains capabilities that are needed for objects which don't have an associated GOT slot (this is inherited from purecap). We could use a different section for these capabilities and not have to cover .desc.data.rel.ro. This would minimize privilege, but I wonder if it adds much security-wise.
|
||
.. code-block:: text | ||
|
||
adrp c16, :got:foo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you mean adrdp? Otherwise this is PC-relative so code and data are 1:1 again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It ends up as adrdp when the linker resolves the relocation. It might be better to just say adrdp here though to avoid confusion.
How do you handle function pointer equality in the presence of dlsym, or even just multiple dynamic relocations for the same descriptor? What actually goes in |
At the moment it's the job of the dynamic linker to make sure only one pair of capabilities is allocated per function pointer while resolving the relocations, and that provides function pointer equality. There's likely scope for improvement here though. |
This makes the Capability Private Data Addressing Register caller-saved, with the following effects: - r19 and r20 are now callee-saved - Removes need for global entry points - All functions start with mov c28, c29 for setting up c28 in the callee. Relocations for direct branches need to jump over this instruction. - Relaxation relocations (R_MORELLO_DESC_CALL and R_MORELLO_DESC_TCALL) are now removed since they are no longer needed.
No description provided.