dynamic feature: capability delegation - #2
Conversation
|
P.S., for now all child PDs of a delegatee PD are seen as delegators, which implies an implicit restriction on the number of available child PDs of PDs with I promise I will fix this design issue later. |
This issue is fixed by the latest commit, which allows a delegatee PD to have more than 16 child PDs, while maximally 16 delegator child PDs. |
Microkit abstractions such as memory regions, IRQs, and IOports can be dynamic by delegating the ability to modify themselves to a PD other than the PDs who use the abstractions. Such a PD is called a 'delegatee' PD, while the dynamic resources are called 'delegated' resources, which are backed up by 'delegated' capabilities. A 'delegatee' PD is a PD that receives all 'delegated' caps of its child PDs or template PDs, which also means a PD without parent is not allowed to delegate the ability to control its resources to others. Signed-off-by: Guangtao Zhu <guangtaozhu@outlook.com>
Signed-off-by: Guangtao Zhu <guangtaozhu@outlook.com>
Delegating an IRQ capability to another PD is of limited use because an IRQ handler is configured to signal a notification associated with the original PD. Delegating the IRQ alone would therefore leave an implicit dependency on the notification capability. Supporting this properly would require delegating or otherwise managing that notification as well. For now, reject delegated IRQs rather than introducing this implicit dependency. Signed-off-by: Guangtao Zhu <guangtaozhu@outlook.com>
This commit redirects delegated IOPort caps to the delegation CNode, while normal non-delegated IOPort caps still stay in the microkit CNode. A range limit is also introduced to prevent the delegated MR caps overlap with the IOPort caps in the delegation CNode. Signed-off-by: Guangtao Zhu <guangtaozhu@outlook.com>
Signed-off-by: Guangtao Zhu <guangtaozhu@outlook.com>
Signed-off-by: Guangtao Zhu <guangtaozhu@outlook.com>
Signed-off-by: Guangtao Zhu <guangtaozhu@outlook.com>
Previously, a delegatee PD assumes all child PDs as delegators, which restricts the maximal number of children a delegatee PD can have (16). This commit introduces 'allow_delegation' to the delegator PDs, which distinguish the PDs who needs a delegation CNode from other normal PDs. Signed-off-by: Guangtao Zhu <guangtaozhu@outlook.com>
This PR adds initial support for capability delegation between a parent protection domain (delegatee) and its direct child protection domains (delegators). It introduces the
delegateePD attribute and thedelegatedattribute for channel ends, memory-region mappings, and x86 I/O ports, with delegated capabilities placed in a per-pair delegation CNode rather than being initially available in the delegator's CSpace.The microkit tool creates and exposes the delegation CNode to the delegatee (parent), supports runtime installation of delegated capabilities, and keeps delegated memory-region frames unmapped at the leaf level so that the delegatee can establish mappings dynamically. IRQ delegation is intentionally not supported. The PR also adds validation for the new SDF semantics, documentation of the delegation model and CSpace layout, and a
cap_delegateexample demonstrating both delegated channel capabilities and demand mapping of a delegated memory region.Conceptually, the CSpace layout for each delegator-delegatee pair looks like:
(for more information, see commit files)