forked from CTSRD-CHERI/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 11
[CHERIoT] Add cheriot_mmio
, cheriot_shared_object
and cheriot_cap_import
attributes
#147
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
Merged
Conversation
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
resistor
reviewed
May 16, 2025
resistor
reviewed
May 17, 2025
resistor
reviewed
May 17, 2025
resistor
reviewed
May 19, 2025
resistor
reviewed
May 20, 2025
resistor
reviewed
May 20, 2025
resistor
reviewed
May 21, 2025
resistor
reviewed
May 21, 2025
resistor
approved these changes
May 26, 2025
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.
Approved once formatting is accepted and CI is green.
Also, please squash before landing. |
Can you rebase rather than merging |
…p_import` attributes The first two are used from the front-end to indicate that an extern global declaration refers to a specific compartment import. The third is the attribute consumed by the back-end to generate the necessary compartment import entry and the correct sequence of instructions when taking the address of the global.
resistor
pushed a commit
that referenced
this pull request
May 27, 2025
…p_import` attributes (#147) The first two are used from the front-end to indicate that an extern global declaration refers to a specific compartment import. The third is the attribute consumed by the back-end to generate the necessary compartment import entry and the correct sequence of instructions when taking the address of the global.
resistor
pushed a commit
that referenced
this pull request
Aug 14, 2025
Since we (Linaro) moved out bots to a new machine, this test has been failing: https://lab.llvm.org/buildbot/#/builders/121/builds/1566 Most of the time, the rss difference is greater than 512 on the first iteration then settles down to 512 for all the rest. ``` starting rss 512 shadow pages: 1024 p = 0xe083e0800000 1536 -> 740 diff 796 1252 -> 740 diff 512 1252 -> 740 diff 512 1252 -> 740 diff 512 1252 -> 740 diff 512 1252 -> 740 diff 512 1252 -> 740 diff 512 1252 -> 740 diff 512 1252 -> 740 diff 512 1252 -> 740 diff 512 p = 0xe083e0800000 passed 1 out of 10 release-shadow.c.tmp: /home/tcwg-buildbot/worker/clang-aarch64-lld-2stage/llvm/compiler-rt/test/hwasan/TestCases/Linux/release-shadow.c:81: int main(): Assertion `success_count > total_count * 0.8' failed. ``` Given that the test was looking for a diff of at least 513, I guess that 512 is ok too. For future reference, the original bot host was running this kernel: Linux 5.15.0-136-generic #147-Ubuntu SMP Sat Mar 15 15:51:36 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux And the new host: Linux 6.8.0-64-generic #67-Ubuntu SMP PREEMPT_DYNAMIC Sun Jun 15 20:23:40 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux Though the new host also has more RAM, so the kernel may be less aggresive with memory management.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The objective of the PR is that of tackling part of #6; in particular,
cheriot_mmio
roughly maps toMMIO_CAPABILITY_WITH_PERMISSIONS
macro,cheriot_shared_object
toSHARED_OBJECT_WITH_PERMISSIONS
and the back-end attributecheriot_cap_import
toIMPORT_CAPABILITY_WITH_PERMISSIONS_HELPER
.The first two -
cheriot_mmio
andcheriot_shared_object
- are used in the front-end to indicate that the declaration of anextern
global refers to a specific compartment import. These two attributes have the same format: they take two values, namely the identifier of the import and the string-encoding of the permissions (e.g.RWcm
).The third,
cheriot_cap_import
, is the attribute consumed by the back-end to generate the necessary compartment import entry and the correct sequence of instructions when taking the address of the global. The value of this last attribute has this format:<export_prefix>,<domain>,<object_name>,<permissions>
.I tested these attributes both in clang and LLVM. The test in clang only confirms that the front-end attributes map to the correct format in the back-end attribute. The test in LLVM is a bit more extensive: it checks that each global declaration in the IR translates to the correct compartment import table entry, and that taking the address of the global is translated to the correct sequence of assembly instructions. It also checks that declaring two different globals that refer to the same import resolve to the same symbol when the address of either global is taken. The test currently does not check that the duplicated declaration does not produce a second repeated import entry (which would nonetheless live in a
.comdat
section), because I didn't find a way to check that a symbol does not appear in the generated assembly.There are a couple things I'm not too sure about: the first is how encoded permissions are translated to an integer (that matches the integer created from the macros mentioned above). The second is where I defined some CHERIoT-related functions.
I ran
git clang-format HEAD~1
before pushing, but it seems to me that some formatting is still wrong.