(ISAv71 Ch 8.18): Unseal is an explicit operation. In CHERI, it requires explicit operation to convert an undereferenceable object into a pointer. CUnseal or CCall.
An alternative architecture would have been one with implicit* unsealing, where a sealed capability could be dereferenced without explicitly unsealing it first, provided that the subsystem attempting the dereference had some kind of ambient authority that permitted it to dereference sealed capabilities of that type. This ambient authority could have taken the form of a protection ring or the otype field of PCC.
A disadvantage of an implicit unseal approach such as the one outlined above is that it is potentially vulnerable to the Confused deputy problem2: the attacker calls a protected subsystem, passing a sealed capability in a parameter that the called subsystem expects to be unsealed. If unsealing is implicit, the protected subsystem can be tricked by the attacker into using its privileges to read or write to memory to which the attacker does not have access.
LLM: how to solve? how about OO constraint? Limit the interfaces? Constrain the parameters?
The disadvantage of the CHERI choice is that protected subsystems need to be careful not to leak capabilities that they have unsealed, for example, by leaving them on the stack when they return to their caller. In an architecture with “implicit unseal”, protected subsystems would just need to delete their ambient authority for the type before returning, and would not need to explicity clean up all the unsealed capabilities that they had created.
Reference: ISAv8
Two types:
Sealed pairs:
CInvoke, a jump-like instruction, allows the two sealed capabilities to be atomatically unsealed as control flow transfers to the code pointed to by the code capability, if their object types match;Sealed entry capabilities:
Usages:
If you could revise
the fundmental principles of
computer system design
to improve security...
... what would you change?