Sealing keys #127
Sealing keys #127
Conversation
… Jon Woodruff, Peter Rugg, Alexandre Joannou, and Franz Fuchs
…sion between Peter Rugg, Jonathan Woodruff, Alexandre Joannou, and Franz Fuchs
There was a problem hiding this comment.
I'm trying to think through the compartmentalization and revocation implications of the programming models this implies. For a compartment that uses sealing to hand out opaque internal references that it unseals for its own use, it's easy and you don't have to worry about the spread of either sealing or unsealing capabilities. You'll want to be able to revoke them before reuse, but that's fine so long as you can leave the CHERI_PERM_SW_VMEM set in the sealer.
(I do fine myself wondering if we could get away with piggybacking on a hypothetical CHERI_PERM_CAN_SEAL architectural permission for CHERI_PERM_SW_VMEM and avoid burning a user permission. I'm finding it hard to imaging that separating those things would be useful. I guess you might allocate an object from an object array, do some initial processing in one compartment, and seal it there, but that's seems needlessly complicated.)
NB: I've not commented on a number of grammatical issues in "Extension to Sealing Keys" and beyond.
| @@ -1742,32 +1742,38 @@ \section{Sealed Keys to Accelerate Typeless Data Sealing} | |||
| This mechanism might be used directly if all objects that will be sealed can be allocated in the same ``heap'', or might be used with indirection to allow sealing any capability with that type. | |||
| In this case, the sealing domain would allocate a table with space for one capability for each instance it intends to seal. | |||
| Every time it wants to seal a capability with that type, it would store it in the table, and seal a capability pointing to that entry, and hand it to untrusted domains. | |||
| To unseal, it would CBuildCap to assert that it belongs to the expected type, and then load the original reference from the table. | |||
| To unseal, it would use \insnref{CBuildCap} to assert that it belongs to the expected type, and then load the original reference from the table. | |||
There was a problem hiding this comment.
"type" appears out of nowhere here and I'm not sure it's the terminology you want.
|
|
||
| Without otypes, it is still possible to ``unseal'' sealed capabilities if you posses a superset capability by rederiving from the superset capability, which can be accelerated with BuildCap. | ||
| Without otypes, it is still possible to ``unseal'' sealed capabilities if you posses a superset capability by rederiving from the superset capability, which can be accelerated with \insnref{CBuildCap}. |
There was a problem hiding this comment.
| Without otypes, it is still possible to ``unseal'' sealed capabilities if you posses a superset capability by rederiving from the superset capability, which can be accelerated with \insnref{CBuildCap}. | |
| Without otypes, it is still possible to ``unseal'' sealed capabilities if you posses a superset capability by rederiving from the superset capability. | |
| This can be accelerated with \insnref{CBuildCap}. |
|
|
||
| Delegation of unsealing: The above typeless sealing is lacking some flexibility versus the full otype system in CHERIv9. | ||
| The above typeless sealing is lacking some flexibility versus the full otype system in CHERI v9. |
| Two compartments having the same powerful capability can both seal and unseal capabilities. | ||
|
|
||
| Furthermore, superset unsealing puts an upper limit of how many different capabilities can be unsealed with one key determined by the size of the memory space authorised by that key. | ||
| In the otype world, a suitable authorising capability allows to unseal as many capabilities as there can concurrently exist in the system. |
There was a problem hiding this comment.
| In the otype world, a suitable authorising capability allows to unseal as many capabilities as there can concurrently exist in the system. | |
| In the otype world, a suitable authorizing capability allows to unseal as many capabilities as there can concurrently exist in the system. |
US spelling
|
|
||
| As defined at the moment, the RISC-V CHERI proposal’s CBuildCap instruction restores the sealed bit from the bag of bits given to it. | ||
| As defined at the moment, the RISC-V CHERI proposal's \insnnoref{CBLD} instruction restores the sealed bit from the bag of bits given to it. |
There was a problem hiding this comment.
I'm not seeing a CBLD in the tree.
|
|
||
| Second, the permissions can be extended by one bit for sealing keys. | ||
| This would allow for manipulations, but also it would be monotonic. | ||
| A memory region authorized by a capability cannot be used a sealed after the the permissions bit has been stripped. |
There was a problem hiding this comment.
| A memory region authorized by a capability cannot be used a sealed after the the permissions bit has been stripped. | |
| A memory region authorized by a capability cannot be used for sealed after the permissions bit has been stripped. |
???
| Third, the format can include a mode bit, which tells whether this is a sealing key capability. | ||
| This allows for manipulations on the capability. | ||
| The sealing key bit can never be cleared, but every non-sealed-key capability can become a sealing key. | ||
| This gives code the power to create their own unsealers with needing to have given an unsealer before. |
There was a problem hiding this comment.
| This gives code the power to create their own unsealers with needing to have given an unsealer before. | |
| This gives code the power to create their own unsealers without needing to have given an unsealer before. |
This extends our thoughts on sealing keys in the experimental section.