Capability compression exceptions

[Mingkai-Li]

Currently, we are using a CHERI-style compression to express bounds in a 128-bit capability. However, some values of the base and end fields are illegal in such a compression format. What should the machine do if such a situation happens? Should we add a new exception type? Or it simply just enter the state of panic in Pure Capstone or the state of unhandleable exception in TransCapstone. @jasonyu1996

[jasonyu1996]

Definitely should not panic. There are two options.

• Exception
• Return a capability with a bound closest to the intended one but we should only do so by shrinking the intended bound not expanding it. If the software wants to make sure the bound is exact, it can always perform extra checks

Ideally we can provide separate sets of instructions for manipulating capability bounds. For now let's get this 2nd one done. Afterwards we can consider the first one.

[Mingkai-Li]

In a real machine, these adjustments to the bounds of the capability should be handled every time we make changes to the bounds (i.e. SHRINK and SPLIT) and every time we make changes to the cursor of the capability. In the simulator, maybe we can just make such changes to the capability when we store a capability to the memory (since that's when we need to translate a capability to its bit representation).

[trevorcarlson]

I think we should reconsider this. Any change in the region could be exploited as a security issue. Instead of shrinking, we could report an error. It would be up to the software to determine if it will be valid or not. This should simplify things. For expanded / precise versions, we could have a feature bit, and then the code would know all values are valid and generate the correct ones.

[jasonyu1996]

I think we should reconsider this. Any change in the region could be exploited as a security issue. Instead of shrinking, we could report an error. It would be up to the software to determine if it will be valid or not. This should simplify things. For expanded / precise versions, we could have a feature bit, and then the code would know all values are valid and generate the correct ones.

Actually there are more options here, beyond what we have mentioned

• allowing expansion but use another capability to limit how far it can expand
• clear tag for any result from unrepresentable capabilities

Beyond this we want to decide how much of this behaviour should be specified and how much should be left to the implementation. Currently we have left the actual capability encoding to the implementation, and considering that this representable/unrepresentable thing depends on the capability encoding, I think we should let the implementation decide something too.

Perhaps we can mandate implementations to provide a "strict mode", which throws errors/clears tags for anything unrepresentable, but let the implementation shrink regions outside this mode.