|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RFC: Boot Domain, domB
Hello, Mixed-criticality and safety-critical systems under development need support for timely boot of multiple domains at system launch -- “Initial Domains” -- with static assignment of resources between them, each isolated from the others and without runtime dependency on a “dom0”-type domain. The Xen hypervisor currently contains a section of fixed policy logic for creation of a single, highly-privileged domain “dom0” at system boot. We would like to establish a shared understanding of best practice for configuration and deployment of disaggregated system launch with multiple domains, for production systems, on both x86 and ARM platforms. Correctness and integrity of system launch is fundamental to system security. Maximizing the commonality between deployed Xen systems enables pooling of risk and widens the applicability of testing that is performed. ## Requirements: * Enable fast launch of multiple domains at system boot. * Obtain the boot materials for Initial Domains -- config, kernel image, optional ramdisk -- from host boot binaries. * A system initialization process that is appropriate for both ARM and x86. * Support minimization of audit work required for safety critical certification * Favour reduction of code size and complexity of highest-privilege components. * Decouple and isolate logic in support of simplifying validation by enabling reasoning about the interfaces between components. * Remove the policy logic for initial distribution of privileges from the hypervisor. * Aim to simplify and consolidate the hypervisor code for system launch. * Allow flexibility of different initial domain configurations by disaggregation to an external component. * Separate the mechanisms of privilege assignment, necessarily within the hypervisor, from the implementation of policy logic assigning them to specific domains. * Support measured launch (e.g. TXT/SKINIT) and verified launch (e.g. Secure Boot) to include the ability to measure/verify any or all Initial Domains. * Support for manageable processes for the system boot binaries. * ie. Consider: creation of files, updates to files, build-time tooling, run-time tooling, dependencies of components. * Note that Device Tree tooling is foreign for booting x86. * Do not make Initial Domain creation depend upon parsing complex data structures, such as a Device Tree, within the hypervisor. * The parsing is unwanted attack surface. * A static, unchanging Device Tree binary used just for hardware-enablement increases commonality across deployments, and is easier to place trust in than one that changes according to the specific installed software configuration. * Support configuration of XSM security labels for the Initial Domains. ## Proposed approach: Provide support for the hypervisor launching an alternative configuration for the first domain launched, revising the all-privileged Dom0 to it being a more capability-constrained “Boot Domain”, DomB. DomB is responsible for starting a set of domains from the material it discovers within its ramdisk. Once they are running, DomB terminates with launch success status indicator, in a step we refer to as “Exit Xen Boot Services”. The domain termination makes it easy to verify that all DomB privileges have been dropped. The Boot Domain need not be granted hardware access capabilities itself; but it does require the capability to create a domain that has each privilege. Since DomB is granted no access to hardware, it is possible for DomB to operate as a PVH domain - and we would advocate for this. In a future iteration of the work: when DomB creates domains and delegates privileges to them, DomB will lose the ability to further delegate the same privileges to other domains. This atomic transfer will be enforced by the hypervisor: a ratchet of decreasing capability. The Boot Domain approach enables flexibility of configuration in system bring up, with the same approach applicable on both ARM and x86 architectures, while minimizing increase in the hypervisor code base. DomB can be implemented in a small, single-purpose kernel, e.g. mini-os or LK, that can easily be audited for certification while maximizing the isolation of the platform launch process. It provides flexibility to support multiple models to include but not limited to: single, all privileged domain, in traditional dom0-style; split privileged domains (control/hardware domains); disaggregated domains; static partitioned domains; or high density, cloned domains (e.g. container farm or fast-fork honeypot). ## Q: How does this change the system boot configuration files? #### Existing practice: The current dom0 initialization materials are: * optional entries on the Xen command line * an OS kernel image * an OS kernel command line, supplied by the bootloader * an optional OS kernel initial ramdisk image #### With the proposal: The domB initialization materials are: * optional entries on the Xen command line * an OS kernel image * an OS kernel command line, supplied by the bootloader * the domB initial ramdisk image The domB initial ramdisk image will contain: * For each Initial Domain: * VM configuration file, including (amongst other things): * any OS kernel command line * standard VM config items, such as RAM allocation, vCPU configuration * XSM security label for the domain * For PV/PVH domains: * an OS kernel image * an optional ramdisk for the VM * An init program to enable the domB kernel to start the Initial Domains. * The domains may be started in parallel, or in sequence, as required - eg. some domains may depend upon storage backends being available, and so be started later in the sequence. The XSM policy will require updating for a domB system. For booting into the traditional highly-privileged dom0 model with this launch process, the most visible effect is migration of the dom0 configuration state and kernel boot binaries into the domB ramdisk. Documentation will be necessary to communicate how to work with this configuration. ## Q: How does this structure affect the TCB? The Xen system components that must be within the TCB of each Initial Domain are: * The hypervisor. * The Boot Domain, domB, which has exited and cannot be restarted without host reboot. It enables the start of VMs with a shorter chain of trust and substantially reduced volume of code in their TCB than available with the traditional dom0 model. Note that running VMs with privileges over other domains will impact the size of the TCB of the VMs that they have privilege over. XSM is able to perform fine-grained confinement which can address this. ## References RFC for “dom0less step 1”, with aim of preparation for Safety Certification Domain Builder Hardware Domain support thanks, Christopher _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |