-
Notifications
You must be signed in to change notification settings - Fork 1
Abstract Resource Capabilities
This section describes a capability system (mechanism) managed by the monitor and used by domains. This is not a requirement for a valid monitor implementation but rather a convenience to more easily describe the semantics of the design.
A capability is defined as a communicable, unforgeable token of authority that references an object (a resource) associated with access rights (operations). Manipulations of capabilities allow managers to implement their policies and the monitor to translate them into valid access configurations.
We propose a capability system with two types of capabilities: 1) resource and 2) revocation.
A resource capability represents the ability to perform the specified operations on the associated object. In our capability system, every resource object has a reference count that tracks how many capabilities apply to it and it is always sufficient to hold a capability to an object to consult its reference count. We assume an initial state, for any system, where there is only one capability per unit of resource with full access to it. Resource capabilities can be split, i.e., consumed, to yield a new pair of capabilities with either the same set of operations as the original one, or any subset of them. This includes the empty set, i.e., a resource capability with no access to the resource. The reference count of the object is incremented to mirror the number of non-empty resource capabilities pointing to it. A split further generates a revocation capability for the created pair.
A revocation capability references a pair of capabilities of any type. Revocation capabilities only support merge operations: a merge consumes the revocation capability and the referenced pair in order to reform the same capability that was split to create them. In other words, a revocation capability allows to undo a split. Revocation capabilities cannot be split.
If it helps the reader, a sequence of splits applied to resource capability creates a tree whose nodes are revocation capabilities and leaves are resource ones. A split replaces a leaf with a revocation node whose children are two new resource capabilities. A merge on a revocation node deletes its sub-tree and replaces the node with the original capability whose split created it.
Capabilities are communicable tokens, i.e., they can be passed between domains. A domain owns a capability if it holds a reference to the capability. By design, at any given point, at most one domain can hold a reference to a given capability.
Capabilities can be transferred between domains. Any domain A that owns a capability X can transfer it to a domain B. In the process, A loses the reference to X and thus the associated authority while B acquires it. To satisfy the visible resource allocation, the monitor requires B to acknowledge X before it can start using it. If B rejects X, X is transferred back to A.
Note that a given domain can own multiple capabilities referencing the same resource. The authority of the domain over the resource is therefore the union of the authority of all its relevant capabilities.
Ownership of capability is different than ownership of a resource. A resource R is owned by a domain A if the root capability in the tree that oversees R is owned by A. This definition implies that A can own R despite not having access to it. This property is essential in order to implement confidential memory while preserving the Popek & Goldberg requirement that a hypervisor must be in full control of the virtualized resources. Note that the second part of the statement is relaxed to only include the set of resources owned by the hypervisor.
%While capabilities can only be referenced by one domain at a time, resources can have multiple references pointing to them. %To ensure exclusive access to a resource, a domain needs to consult the reference count associated with the capability's object. %By construction, if the reference count is one, the only other capabilities pointing to the same resource are either empty or revocation ones.
The manager remains in full control of the resources it allocates to other domains, as long as it owns the corresponding revocation capability. Whenever the manager invokes its revocation handle, the model guarantees the return of the resource.
Resource capabilities provide fine-grained control over the modality of sharing resources, i.e, it provides at least as much control as the underlying access control mechanism. Thus, in a valid implementation of the model, the manager is able to control the access rights granted to a domain.
By construction, the model allows any domain to enumerate its capabilities at any time. To ensure exclusive access, it is sufficient for a domain to consult the reference count of the associated resource and thus ensure it holds all the non-empty resource capabilities to this object. Any other capability associated with this object has to either be empty or a revocation one. By the monotonicity of the split operation, no domain holding an empty capability can increase its access right. By the visibility of revocation, the domain will see any revocation of the associated resource and preserve its confidentiality by, \eg zeroing out the resource's content.
The system described in this section is far more general than the limited case of confidential memory. As demonstrated, it reduces confidential computing to the decoupling of management from access control. When it comes to particular resources, it allows fine-grained control over resource sharing. It further decouples exclusive access to a resource from its ownership. By allowing all domains to act as both clients and managers, while preserving the managerial chain, the monitor decouples management prerogative from hardware privileged modes. All of these are strong results that allow any form of compartmentalization and nesting of domains. It is, for example, possible to implement sandboxing mechanisms on top of this model and combine them with confidential computing guarantees.
By design, the description of the model mentioned resources, without specifying which ones. This is to allow the system to manage various types of resources, both physical or abstract. While memory is the main focus of our implementation in the next section, we believe the model can include PCI devices, interrupt handling, the ability to create new domains, establishing communications between domains, and potentially even CPU resources. Our intuition, that future work will explore, is that the Popek & Goldberg theorem can be generalized to include any resource for which there is an access control mechanism that is solely available in supervisor mode.