Re: [Xen-devel] [PATCH v3 2/7] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 10/19/2017 07:58 AM, Jan Beulich wrote:
> > > > 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
If this operation is going to be allowed at all (and I agree it has
valid use cases), then there won't be a privilege relationship between
(d) and (t) to check - they'll both be (somewhat related) domUs as far
as Xen can tell.  If this hypercall isn't used, adding a new hypercall
(subop) is the only way I'd see to do it - and that seems very redundant
as it'd need to do all the same checks except for the one about the
relationship between (d) and (t).  I don't see the reason why the
existing hypercall should deny being used for that purpose once it's
possible using other means.

The only possible problem that springs to mind is a restricted kernel
interface (such as the one used by QEMU in dom0 that restricts to a
single target domain) that now doesn't realize it's relaying an
operation that also requires permission over (t) after only checking
that the origin is allowed to modify (d).

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