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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.02.16 at 18:24, <JBeulich@xxxxxxxx> 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.
> 
>> 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

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