Modeling potential attacks to our secure compartment switch model

[0152la]

In #55 , we introduced what we believe is a secure model of performing compartment switching. At a high-level, the idea is to provide compartments a capability (sealed with lpb type, meaning to be used in load-pair-branch instructions) which points to the DDC/PCC to be used by switch_compartment. These capabilities are within the memory "owned" by switch_compartment, and not accessible to compartments, due to DDC bounds. Compartments can provide an id to switch_compartment to perform the transition to another compartment (data for which is similarly stored in memory covered by switch_compartment DDC).

To emphasise this, and to future proof the model, we introduce a number of negative examples:

• In Improve compartment example security #55 , we also introduce example try_deref, where a compartment attempts to dereference its provided capability, which would essentially provide it with the DDC used by switch_compartment. This fails, as the provided capability is sealed.
• In Add two negative examples #57 , example update_ddc emulates a program where the address of the DDC to be used by switch_compartment is leaked (this is similar to the above, except the provided capability would not be sealed). The compartment attempts to load the DDC, but fails, as it lies outside its own DDC bounds.
• In Add two negative examples #57 , example redirect_clr attempts to install a clr which points to a malicious function once switch_compartment exits. However, the only way for the compartment to derive a capability to install in clr is to use its own PCC, meaning that the malicious function would lie outside executable bounds upon returning.

The existing examples provide one method of implementing the above attempts at breaking CHERI security guarantees - there might be other ways of implementing the above ideas. The question for this issue is are there any other potential methods of attempting to subvert security guarantees in our model.

[0152la]

I think what we should be focusing on is the information provided by the containers themselves to switch_compartment. This is essentially the ldpblr instruction, and the parameter indicating which compartment to jump to. In the current implementation, the id is not checked to see if it lies within expected bounds, so reading uninitialized memory within switch_compartment is possible (the fix is more an exercise in engineering and will be done in due course). Other questions are can we somehow affect the capabilities loaded by ldpblr, or any other information loaded during switch_compartment execution.