Add example showing inter-compartment switch #53

0152la · 2021-12-03T14:38:42Z

This example adds a second compartment, and shows a possible design to
achieve inter-compartment switching without (much) privilege escalation.
In this file, we setup compartment information within array comps
(main.c:84). This information will be used by the assembly function
switch_compartment. Further, we save a capability to
switch_compartment() in a register (main.c:102), to be able to call
it from a bounded-PCC context, as well as a capability defining the area
of memory with compartment information (main.c:101). These could be
added to the memory area of each created compartment for better
security, as well as sealed.

Our two compartments provide one entry point each, comp_f_fn
(shared.S:93), and comp_g_fn (shared.S:109). The design is that
compartment f will perform a switch to compartment g, which performs
some observable action (in this instance, sets a specific memory
location to a specific integer value). The switching process in (almost)
entirely bound within switch_compartment, on the execution side, and
the memory area with compartment information, for memory access. We note
almost, as the executable area is approximated (main.c:96).

ltratt · 2021-12-03T14:48:42Z

hybrid/compartment_examples/inter_comp_call/main.c

+	void* __capability comps_addr = (void* __capability) &comps;
+    comps_addr = cheri_bounds_set(comps_addr, COMP_COUNT * COMP_SIZE);
+
+	asm("mov c19, %w0\n\t"


I think there might be a mix of tabs and spaces here? Let's use all spaces.

Ah, well, this will be fixed by the subsequent clang-format process (which I haven't applied for the PR at this point). I prefer spaces myself, but clang-format seems to put tabs.

Does it? Ye gods! In general, it's best to do clang-format before opening a PR. And then if it does mix tabs and spaces we'll just have to live with it (we can still grumble about it though :)).

For ease, I've just ran one now [1]. In the future, I will run one at the point of making the PR, and the point of merging (until I hopefully am able to do the hooks thing).

[1] 5ae74cf

ltratt · 2021-12-03T14:51:06Z

You're going to have to spell out a few things in more details so that idiots like me can understand what's going on :) For example, what does "shows a possible design to achieve inter-compartment switching without (much) privilege escalation" mean? I guess this PR is still subject to the same "any compartment can get access to another compartments DDC and read/write to its heap" as the previous PR?

0152la · 2021-12-03T14:58:53Z

I guess this PR is still subject to the same "any compartment can get access to another compartments DDC and read/write to its heap" as the previous PR?

Yes, however I briefly mention [1]:

These could be added to the memory area of each created compartment for better security, as well as sealed.

This might be a good direction for a future PR, or even this one, to make it slightly meatier.

You're going to have to spell out a few things in more details so that idiots like me can understand what's going on

The top-level comment is a high-level view, so it's kept intentionally less exact (to not be overly verbose with detail), while the steps are more spelled out in the in-line comments. Do those not help?

[1] https://github.com/capablevms/cheri-examples/pull/53/files#diff-bd3f0e982085d3f24aabff1a3429bddce60c0605c9d6047f8354c515a685b477R8

0152la · 2021-12-03T15:05:07Z

I forgot to mention in the leading comment, there are a things I'd like to improve. Primarily, the PCC bounds on switch_compartment are approximate and manual [1], as well as the bounds on the compartment functions [2]. However, I am unaware of how to derive these in code (C or asm), without doing something similar as ELF inspection that the Android example does.

And the security can (and should) be tightened further, primarily via sealing capabilities for the compartment switcher (DDC/PCC) and copying them in memory for each specific compartment. I have an idea of how to do that as well in here, and could integrate it in this PR, or a separate "security strengthening" pass.

[1] https://github.com/capablevms/cheri-examples/pull/53/files#diff-bd3f0e982085d3f24aabff1a3429bddce60c0605c9d6047f8354c515a685b477R96
[2] https://github.com/capablevms/cheri-examples/pull/53/files#diff-bd3f0e982085d3f24aabff1a3429bddce60c0605c9d6047f8354c515a685b477R128

ltratt · 2021-12-03T15:40:50Z

These could be added to the memory area of each created compartment for better security, as well as sealed.

This might be a good direction for a future PR, or even this one, to make it slightly meatier.

My guess is that the easiest way of handling this is for the compartment switcher to keep these things private to itself. But we can handle that in a later PR.

I have an idea of how to do that as well in here, and could integrate it in this PR, or a separate "security strengthening" pass.

Sounds like a good idea for the next PR :)

ltratt · 2021-12-03T15:41:47Z

hybrid/compartment_examples/inter_comp_call/main.c

+void executive_switch(struct comp c)
+{
+	void *__capability switch_cap = (void *__capability) switch_compartment;
+	switch_cap = cheri_bounds_set(switch_cap, 80 * 4);


Ah, are these used as PCC bounds?

Yes, hardcoded approximate bounds so things can execute, since I'm unaware of a way to compute this at compile-time, if it is possible. They would potentially be handled by the linker, an an actual implementation. Could maybe use labels, to mark start/end?

Good question -- I have no idea! Certainly it should be possible via ELF but it might be possible some other way, though I doubt that it's portable either way. I'm fine with punting on that for this PR. Maybe add an issue to this repo "How to calculate a function's length at runtime" as we'll then be able to ask Edd for suggestions (he knows more about such things than I do!).

Opened #54 to at least start a conversation maybe.

ltratt · 2021-12-03T15:42:06Z

hybrid/compartment_examples/inter_comp_call/main.c

+	new_comp.ddc = comp_ddc;
+
+	void *__capability comp_fn = (void *__capability) _comp_fn;
+	comp_fn = cheri_bounds_set(comp_fn, 40);


I guess these are also PCC bounds?

Yes, bounds as well.

Can I suggest we use pcc somewhere in the var name? Maybe something like comp_pcc or similar? Failing that, a comment will help readers like me.

I've added a comment which helpfully clarifies things.

At this point, I think the following is a rather core property of CHERI, and maybe we should make it obvious somewhere: creating a capability which has the value field the address of a function, then calling (or jumping to) that capability implies installing that capability as the PCC.

ltratt · 2021-12-06T14:18:54Z

Please squash.

This example adds a second compartment, and shows a possible design to achieve inter-compartment switching without (much) privilege escalation. In this file, we setup compartment information within array `comps` (`main.c:84`). This information will be used by the assembly function `switch_compartment`. Further, we save a capability to `switch_compartment()` in a register (`main.c:102`), to be able to call it from a bounded-PCC context, as well as a capability defining the area of memory with compartment information (`main.c:101`). These could be added to the memory area of each created compartment for better security, as well as sealed. Our two compartments provide one entry point each, `comp_f_fn` (`shared.S:93`), and `comp_g_fn` (`shared.S:109`). The design is that compartment `f` will perform a switch to compartment `g`, which performs some observable action (in this instance, sets a specific memory location to a specific integer value). The switching process in (almost) entirely bound within `switch_compartment`, on the execution side, and the memory area with compartment information, for memory access. We note almost, as the executable area is approximated (`main.c:96`).

0152la · 2021-12-06T14:22:21Z

Squashed.

ltratt · 2021-12-06T14:22:46Z

bors r+

bors · 2021-12-06T14:24:36Z

Build succeeded:

buildbot/capablevms-test-script

0152la assigned ltratt and jacobbramley Dec 3, 2021

ltratt reviewed Dec 3, 2021

View reviewed changes

0152la force-pushed the intra_comp_switch branch from a30278b to 07f387e Compare December 6, 2021 14:22

bors bot merged commit fcf29cc into capablevms:master Dec 6, 2021

0152la deleted the intra_comp_switch branch December 6, 2021 14:52

0152la mentioned this pull request Jan 12, 2022

Improve compartment example security #55

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add example showing inter-compartment switch #53

Add example showing inter-compartment switch #53

0152la commented Dec 3, 2021

ltratt Dec 3, 2021

0152la Dec 3, 2021

ltratt Dec 3, 2021

0152la Dec 3, 2021

ltratt Dec 3, 2021

ltratt commented Dec 3, 2021

0152la commented Dec 3, 2021

0152la commented Dec 3, 2021

ltratt commented Dec 3, 2021

ltratt Dec 3, 2021

0152la Dec 3, 2021

ltratt Dec 3, 2021

0152la Dec 6, 2021

ltratt Dec 6, 2021

ltratt Dec 3, 2021

0152la Dec 3, 2021

ltratt Dec 3, 2021

0152la Dec 6, 2021

ltratt commented Dec 6, 2021

0152la commented Dec 6, 2021

ltratt commented Dec 6, 2021

bors bot commented Dec 6, 2021

Add example showing inter-compartment switch #53

Add example showing inter-compartment switch #53

Conversation

0152la commented Dec 3, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ltratt commented Dec 3, 2021

0152la commented Dec 3, 2021

0152la commented Dec 3, 2021

ltratt commented Dec 3, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ltratt commented Dec 6, 2021

0152la commented Dec 6, 2021

ltratt commented Dec 6, 2021

bors bot commented Dec 6, 2021