Xen supports disaggregation of various support and management functions into their own domains; this is often done for security and robustness reasons. In Xen 4.3 additional functionality was introduced to allow further disaggregation: the Xen Security Modules mechanism was enhanced to make it possible to delegate various domain control hypercalls to particular other domains, rather than only permitting use by dom0. However the several affected hypercall implementations were originally written to be used only by the totally-privileged dom0, and have not been reviewed for security when exposed to supposedly-only-semi-privileged disaggregated management domains. But such management domains are (in such a design) to be seen as potentially hostile, e.g. due to privilege escalation following exploitation of a bug in the management domain. As a result, the potential security benefits of toolstack disaggregation are not always fully realised. This constitutes a breach of the enhanced security promises implied by the Xen APIs in Xen in 4.3 and later. The affected hypercalls are: HYPERVISOR_domctl: The majority of the XEN_DOMCTL_* subops are affected. Exceptions are listed below. HYPERVISOR_sysctl: All XEN_SYSCTL_ subops are affected. HYPERVISOR_memory_op: A small number of XENMEM_* subops are affected. See below. HYPERVISOR_tmem_op: All TMEMC_ sub-subops of the TMEM_CONTROL subop are affected. The majority of the domctls are subject to this issue. Prior to 4.3, only the following domctls were disaggregatable, and they are NOT affected by these problems: XEN_DOMCTL_ioport_mapping XEN_DOMCTL_bind_pt_irq XEN_DOMCTL_memory_mapping XEN_DOMCTL_unbind_pt_irq The implementations of these were written with semi-trusted callers in mind. Only the following memory op subops are affected: XENMEM_set_pod_target XENMEM_get_pod_target XENMEM_claim_pages The remainder of the memory ops were written with untrusted or semi-trusted callers in mind.
Domains deliberately given partial management control may be able to deny service to the entire host or even escalate their privileges. As a result, in a system designed to enhance security by radically disaggregating the management, the security may be reduced. But, the security will be no worse than a non-disaggregated design. #### VULNERABLE SYSTEMS This issue is only relevant to systems which intend to increase security through the use of advanced disaggregated management techniques. This does not include systems using libxl, libvirt, xm/xend, XCP/XenServer, OpenStack or CloudStack (unless substantially modified or supplemented, as compared to versions supplied by the respective upstreams). This issue is not relevant to stub device models, driver domains, or stub xenstored. Those disaggregation techniques do not rely on granting the semi-privileged support domains access to the affected interfaces, and are believed to provide the intended security benefits. This issue is only relevant to Xen 4.3 and xen-unstable, and not to any earlier version. PROCESS FOR VULNERABILITIES IN AFFECTED INTERFACES Until the interfaces have been properly reviewed for security against hostile callers, the Xen.org security team intends (subject of course to the permission of anyone disclosing to us) to handle these and future vulnerabilities in these interfaces in public, as if they were normal non-security-related bugs. This applies only to bugs which do no more than reduce the security of a radically disaggregated system to the security of a non-disaggregated one. Here a "radically disaggregated system" is one which uses the XSM mechanism to delegate the affected interfaces to other-than-fully-trusted domains. This policy does not apply to bugs which affect stub device models, driver domains, or stub xenstored - even if those bugs do no worse than reduce the security of such a system to one whose device models, backend drivers, or xenstore, run in dom0. The list of interfaces which are subject to the above process exception are listed in the Xen Source tree in docs/misc/xsm-flask under the heading "Security Status of dom0 disaggregation". This document is also available at <a href="http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt">http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt</a>. We intend that currently-known problems will be publicly disclosed on the xen-devel mailing list, as normal bug reports, at the expiry of the XSA-77 embargo. In the meantime the list below may be helpful.