[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 11/18] xen: use XSM instead of IS_PRIV where duplicated
On 08/06/2012 11:18 AM, Jan Beulich wrote: >>>> On 06.08.12 at 16:32, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote: >> --- a/xen/arch/x86/domctl.c >> +++ b/xen/arch/x86/domctl.c >> @@ -54,6 +54,26 @@ long arch_do_domctl( >> >> switch ( domctl->cmd ) >> { >> + /* TODO: the following do not have XSM hooks yet */ >> + case XEN_DOMCTL_set_cpuid: >> + case XEN_DOMCTL_suppress_spurious_page_faults: >> + case XEN_DOMCTL_debug_op: >> + case XEN_DOMCTL_gettscinfo: >> + case XEN_DOMCTL_settscinfo: >> + case XEN_DOMCTL_audit_p2m: >> + case XEN_DOMCTL_gdbsx_guestmemio: >> + case XEN_DOMCTL_gdbsx_pausevcpu: >> + case XEN_DOMCTL_gdbsx_unpausevcpu: >> + case XEN_DOMCTL_gdbsx_domstatus: >> + /* getpageframeinfo[23] will leak XEN_DOMCTL_PFINFO_XTAB on target GFNs >> */ > > Is that to state that the patch introduces a leak here? Or are you > trying to carefully tell us you spotted a problem in the existing > code? This is an information leak, not a memory leak. It's a (minor) problem with the placement of the existing XSM hooks allowing a domain to query information on remote domains. A later patch fixes this by adding an XSM hook for the entire query operation. >> + case XEN_DOMCTL_getpageframeinfo2: >> + case XEN_DOMCTL_getpageframeinfo3: >> + if ( !IS_PRIV(current->domain) ) >> + return -EPERM; >> + } >> + >> + switch ( domctl->cmd ) >> + { >> >> case XEN_DOMCTL_shadow_op: >> { >> --- a/xen/arch/x86/hvm/hvm.c >> +++ b/xen/arch/x86/hvm/hvm.c >> @@ -3366,12 +3366,12 @@ static int hvmop_set_pci_intx_level( >> if ( (op.domain > 0) || (op.bus > 0) || (op.device > 31) || (op.intx > >> 3) ) >> return -EINVAL; >> >> - rc = rcu_lock_remote_target_domain_by_id(op.domid, &d); >> - if ( rc != 0 ) >> - return rc; >> + d = rcu_lock_domain_by_id(op.domid); >> + if ( d == NULL ) >> + return -ESRCH; >> >> rc = -EINVAL; >> - if ( !is_hvm_domain(d) ) >> + if ( d == current->domain || !is_hvm_domain(d) ) > > What's wrong with rcu_lock_remote_target_domain_by_id() here > and in other places below? I think this minimally would deserve > a comment in the patch description, the more that this huge a > patch is already bad enough to look at. > > Jan > The main reason for this change is that rcu_lock_remote_target_domain_by_id calls IS_PRIV, and this patch is attempting to remove the duplicated calls. Would you prefer making another rcu_lock_* function that only checks against current->domain and doesn't include the IS_PRIV_FOR check? -- Daniel De Graaf National Security Agency _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |