[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 2/7] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin
>>> On 19.10.17 at 04:36, <blackskygg@xxxxxxxxx> wrote: > --- a/xen/include/xsm/dummy.h > +++ b/xen/include/xsm/dummy.h > @@ -516,7 +516,8 @@ static XSM_INLINE int > xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1, > static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, > struct domain *t) > { > XSM_ASSERT_ACTION(XSM_TARGET); > - return xsm_default_action(action, d, t); > + return xsm_default_action(action, current->domain, d) ?: > + xsm_default_action(action, current->domain, t); > } When all three domains are different, how does the changed policy reflect the original "d has privilege over t" requirement? I understand you want to relax the current condition, but this shouldn't come at the price of granting access when access should be denied. Nor the inverse - the current domain not having privilege over both does also not mean d doesn't have the necessary privilege over t. I continue to think that you can't validly retrofit the new intended functionality onto the existing hypercall, even if nothing except the permission check needs to be different. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |