From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?) Date: Tue, 23 Feb 2016 10:28:36 -0700 Message-ID: <56CCA4D402000078000D5591@prv-mh.provo.novell.com> References: <20160217172808.GB3723@citrix.com> <20160219160539.GV3723@citrix.com> <56CAFEE302000078000D4A74@prv-mh.provo.novell.com> <20160223143130.GE3723@citrix.com> <56CC8CD602000078000D54A5@prv-mh.provo.novell.com> <20160223170953.GI3723@citrix.com> <56CCA3F202000078000D5586@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aYGlO-0007nA-Oq for xen-devel@lists.xenproject.org; Tue, 23 Feb 2016 17:28:42 +0000 In-Reply-To: <56CCA3F202000078000D5586@prv-mh.provo.novell.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , PaulDurrant , Anthony PERARD , Xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 23.02.16 at 18:24, wrote: >>>> On 23.02.16 at 18:09, wrote: >> On Tue, Feb 23, 2016 at 08:46:14AM -0700, Jan Beulich wrote: >>> >>> On 23.02.16 at 15:31, wrote: >>> > On Mon, Feb 22, 2016 at 04:28:19AM -0700, Jan Beulich wrote: >>> >> >>> On 19.02.16 at 17:05, wrote: >>> >> > On Wed, Feb 17, 2016 at 05:28:08PM +0000, Wei Liu wrote: >>> >> >> Hi all >>> >> >> >>> >> >> Tools people are in the process of splitting libxenctrl into a set of >>> >> >> stable libraries. One of the proposed libraries is libxendevicemodel >>> >> >> which has a collection of APIs that can be used by device model. >>> >> >> >>> >> >> Currently we use QEMU as reference to extract symbols and go through >>> >> >> them one by one. Along the way we discover QEMU is using some tools >>> >> >> only HVMOPs. >>> >> >> >>> >> >> The list of tools only HVMOPs used by QEMU are: >>> >> >> >>> >> >> #define HVMOP_track_dirty_vram 6 >>> >> >> #define HVMOP_modified_memory 7 >>> >> >> #define HVMOP_set_mem_type 8 >>> >> >> #define HVMOP_inject_msi 16 >>> >> >> #define HVMOP_create_ioreq_server 17 >>> >> >> #define HVMOP_get_ioreq_server_info 18 >>> >> >> #define HVMOP_map_io_range_to_ioreq_server 19 >>> >> >> #define HVMOP_unmap_io_range_from_ioreq_server 20 >>> >> >> #define HVMOP_destroy_ioreq_server 21 >>> >> >> #define HVMOP_set_ioreq_server_state 22 >>> >> >> >>> >> > >>> >> > In the process of ploughing through QEMU symbols, there are some domctls >>> >> > and physdevops used to do passthrough. To make passthrough APIs in >>> >> > libxendevicemodel we need to stabilise them as well. Can I use the same >>> >> > trick __XEN_TOOLS_STABLE__ here? If not, what would be the preferred way >>> >> > of doing this? >>> >> > >>> >> > PASSTHRU >>> >> > `xc_domain_bind_pt_pci_irq` `XEN_DOMCTL_bind_pt_irq` >>> >> > `xc_domain_ioport_mapping` `XEN_DOMCTL_ioport_mapping` >>> >> > `xc_domain_memory_mapping` `XEN_DOMCTL_memory_mapping` >>> >> > `xc_domain_unbind_msi_irq` `XEN_DOMCTL_unbind_pt_irq` >>> >> > `xc_domain_unbind_pt_irq` `XEN_DOMCTL_unbind_pt_irq` >>> >> > `xc_domain_update_msi_irq` `XEN_DOMCTL_bind_pt_irq` >>> >> > `xc_physdev_map_pirq` `PHYSDEVOP_map_pirq` >>> >> > `xc_physdev_map_pirq_msi` `PHYSDEVOP_map_pirq` >>> >> > `xc_physdev_unmap_pirq` `PHYSDEVOP_unmap_pirq` >>> >> >>> >> Mechanically I would say yes, but anything here which is also on >>> >> the XSA-77 waiver list would first need removing there (with >>> >> proper auditing and, if necessary, fixing). >>> >> >>> > >>> > I admit I failed to parse xsm-flask.txt and XSA-77 and its implication, >>> > so let's take a concrete example instead. >>> > >>> > Say, now I need to stabilise XEN_DOMCTL_pin_mem_cacheattr, which is on >>> > the list of domctls listed in xsm-flask.txt (presumably that's the >>> > waiver list you talked about). >>> > >>> > You said "needs removing there", and xsm-flask.txt says "suops not >>> > listed here are considered safe for disaggregation", so the implication >>> > is that we need to make XEN_DOMCTL_pin_mem_cacheattr safe for >>> > disaggregation in order to move it off the list. Is this correct? >>> >>> Yes. >>> >>> > And in order to make it safe for disaggregation, I need to add adequate >>> > XSM checks for it. Is this correct? >>> >>> Well, that depends on what accessibility scope you mean to give >>> it: If domains other than the hardware and control domain are >>> meant to be permitted to access this with the dummy policy, then >> >> All the domctls and physdev ops are going to used by device model. So >> it is going to be either Dom0 or stub device model domain. > > Right, but a stub domain needs to be treated as untrusted, so in > a way it's even worse than tool stack disaggregation. > >> I do notice the following paragraph in xsm-flask.txt: >> >> 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. >> >> Not sure how it changes the perspective. > > This tightens things (whereas I get the impression you view it as > relaxing them), in that issues in these interfaces which can be > exploited by any of the named entities would still be security > issues. And note how, using your example, xsm/dummy.h enforces XSM_PRIV for XEN_DOMCTL_pin_mem_cacheattr. Jan