[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2] domctl: tighten XEN_DOMCTL_*_permission
Hi, I see possible issue with this patch. Can someone clarify - did I get everything correctly? On Tue, May 6, 2014 at 4:08 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote: > With proper permission (and, for the I/O port case, wrap-around) checks > added (note that for the I/O port case a count of zero is now being > disallowed, in line with I/O memory handling): > > XEN_DOMCTL_irq_permission: > XEN_DOMCTL_ioport_permission: > > Of both IRQs and I/O ports there is only a reasonably small amount, so > there's no excess resource consumption involved here. Additionally > they both have a specialized XSM hook associated. > > XEN_DOMCTL_iomem_permission: > > While this also has a specialized XSM hook associated (just like > XEN_DOMCTL_{irq,ioport}_permission), it's not clear whether it's > reasonable to expect XSM to restrict the number of ranges associated > with a domain via this hook (which is the main resource consumption > item here). > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > --- > v2: Fix off-by-one in XEN_DOMCTL_ioport_permission bounds checking. > > --- a/docs/misc/xsm-flask.txt > +++ b/docs/misc/xsm-flask.txt > @@ -72,9 +72,7 @@ __HYPERVISOR_domctl (xen/include/public/ > * XEN_DOMCTL_getvcpucontext > * XEN_DOMCTL_max_vcpus > * XEN_DOMCTL_scheduler_op > - * XEN_DOMCTL_irq_permission > * XEN_DOMCTL_iomem_permission > - * XEN_DOMCTL_ioport_permission > * XEN_DOMCTL_gethvmcontext > * XEN_DOMCTL_sethvmcontext > * XEN_DOMCTL_set_address_size > --- a/xen/arch/x86/domctl.c > +++ b/xen/arch/x86/domctl.c > @@ -46,6 +46,8 @@ static int gdbsx_guest_mem_io( > return (iop->remain ? -EFAULT : 0); > } > > +#define MAX_IOPORTS 0x10000 > + > long arch_do_domctl( > struct xen_domctl *domctl, struct domain *d, > XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) > @@ -72,13 +74,11 @@ long arch_do_domctl( > unsigned int np = domctl->u.ioport_permission.nr_ports; > int allow = domctl->u.ioport_permission.allow_access; > > - ret = -EINVAL; > - if ( (fp + np) > 65536 ) > - break; > - > - if ( np == 0 ) > - ret = 0; > - else if ( xsm_ioport_permission(XSM_HOOK, d, fp, fp + np - 1, allow) > ) > + if ( (fp + np) <= fp || (fp + np) > MAX_IOPORTS ) > + ret = -EINVAL; > + else if ( !ioports_access_permitted(current->domain, > + fp, fp + np - 1) || > + xsm_ioport_permission(XSM_HOOK, d, fp, fp + np - 1, allow) > ) > ret = -EPERM; > else if ( allow ) > ret = ioports_permit_access(d, fp, fp + np - 1); > @@ -719,7 +719,6 @@ long arch_do_domctl( > > case XEN_DOMCTL_ioport_mapping: > { > -#define MAX_IOPORTS 0x10000 > struct hvm_iommu *hd; > unsigned int fgp = domctl->u.ioport_mapping.first_gport; > unsigned int fmp = domctl->u.ioport_mapping.first_mport; > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -790,7 +790,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe > > if ( pirq >= d->nr_pirqs ) > ret = -EINVAL; > - else if ( xsm_irq_permission(XSM_HOOK, d, pirq, allow) ) > + else if ( !pirq_access_permitted(current->domain, pirq) || pirq_access_permitted() checks a range. Range can be added only with pirq_permit_access() function call. The only place where pirq_permit_access() is called - is following *else if* branch. But it will be never called - pirq_access_permitted() will return 0 if range does not exist. As result - it is impossible to add irq, even if XSM allows this. The same is true for iomem_access_permitted() function call. > + xsm_irq_permission(XSM_HOOK, d, pirq, allow) ) > ret = -EPERM; > else if ( allow ) > ret = pirq_permit_access(d, pirq); > @@ -809,7 +810,9 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xe > if ( (mfn + nr_mfns - 1) < mfn ) /* wrap? */ > break; > > - if ( xsm_iomem_permission(XSM_HOOK, d, mfn, mfn + nr_mfns - 1, > allow) ) > + if ( !iomem_access_permitted(current->domain, > + mfn, mfn + nr_mfns - 1) || > + xsm_iomem_permission(XSM_HOOK, d, mfn, mfn + nr_mfns - 1, > allow) ) > ret = -EPERM; > else if ( allow ) > ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1); > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel > -- Andrii Tseglytskyi | Embedded Dev GlobalLogic www.globallogic.com _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |