Skip to content

Conversation

xdoardo
Copy link
Collaborator

@xdoardo xdoardo commented May 16, 2025

The objective of the PR is that of tackling part of #6; in particular, cheriot_mmio roughly maps to MMIO_CAPABILITY_WITH_PERMISSIONS macro, cheriot_shared_object to SHARED_OBJECT_WITH_PERMISSIONS and the back-end attribute cheriot_cap_import to IMPORT_CAPABILITY_WITH_PERMISSIONS_HELPER.

The first two - cheriot_mmio and cheriot_shared_object - are used in the front-end to indicate that the declaration of an extern 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.

Copy link
Collaborator

@resistor resistor left a 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.

@resistor
Copy link
Collaborator

Also, please squash before landing.

@resistor
Copy link
Collaborator

Can you rebase rather than merging cheriot into your branch? Ideally this should go in as a single commit

…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.
@xdoardo xdoardo merged commit a17a9a2 into CHERIoT-Platform:cheriot May 27, 2025
8 checks passed
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants