Re: [Xen-devel] Domctl and physdevop for passthrough (Was: Re: Stabilising some tools only HVMOPs?)

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Feb 23, 2016 at 10:24:50AM -0700, Jan Beulich wrote:
> >>> On 23.02.16 at 18:09, <wei.liu2@xxxxxxxxxx> wrote:
> > On Tue, Feb 23, 2016 at 08:46:14AM -0700, Jan Beulich wrote:
> >> >>> On 23.02.16 at 15:31, <wei.liu2@xxxxxxxxxx> wrote:
> >> > On Mon, Feb 22, 2016 at 04:28:19AM -0700, Jan Beulich wrote:
> >> >> >>> On 19.02.16 at 17:05, <wei.liu2@xxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel