From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?) Date: Tue, 23 Feb 2016 17:55:30 +0000 Message-ID: <20160223175530.GA23681@citrix.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 1aYHBa-000188-OA for xen-devel@lists.xenproject.org; Tue, 23 Feb 2016 17:55:46 +0000 Content-Disposition: inline In-Reply-To: <56CCA3F202000078000D5586@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Ian Jackson , PaulDurrant , Anthony PERARD , Xen-devel List-Id: xen-devel@lists.xenproject.org On Tue, Feb 23, 2016 at 10:24:50AM -0700, Jan Beulich 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. > Yes, I agree. > > 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. > Indeed. I was thinking that relaxes things and got very confused (couldn't even convince myself). Your explanation makes more sense. Wei. > Jan