[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 03/21] xen: allow console_io hypercalls from certain DomUs



On Mon, 9 Jul 2018, Julien Grall wrote:
> Hi,
> 
> On 07/07/18 00:11, Stefano Stabellini wrote:
> > Introduce an is_console option to allow certain classes of domUs to use
> > the Xen console. Specifically, it will be used to give console access to
> > all domUs started from Xen from information on device tree.
> > 
> > Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
> > CC: andrew.cooper3@xxxxxxxxxx
> > CC: George.Dunlap@xxxxxxxxxxxxx
> > CC: ian.jackson@xxxxxxxxxxxxx
> > CC: jbeulich@xxxxxxxx
> > CC: konrad.wilk@xxxxxxxxxx
> > CC: tim@xxxxxxx
> > CC: wei.liu2@xxxxxxxxxx
> > CC: dgdegra@xxxxxxxxxxxxx
> > ---
> > Changes in v2:
> > - introduce is_console
> > - remove #ifdefs
> > ---
> >   xen/include/xen/sched.h | 2 ++
> >   xen/include/xsm/dummy.h | 2 ++
> >   xen/xsm/flask/hooks.c   | 5 ++++-
> >   3 files changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
> > index 99d2af2..d66cec0 100644
> > --- a/xen/include/xen/sched.h
> > +++ b/xen/include/xen/sched.h
> > @@ -379,6 +379,8 @@ struct domain
> >       bool             auto_node_affinity;
> >       /* Is this guest fully privileged (aka dom0)? */
> >       bool             is_privileged;
> > +    /* Can this guest access the Xen console? */
> > +    bool             is_console;
> >       /* Is this a xenstore domain (not dom0)? */
> >       bool             is_xenstore;
> >       /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
> > diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> > index ff6b2db..3888817 100644
> > --- a/xen/include/xsm/dummy.h
> > +++ b/xen/include/xsm/dummy.h
> > @@ -230,6 +230,8 @@ static XSM_INLINE int
> > xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
> >   static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int
> > cmd)
> >   {
> >       XSM_ASSERT_ACTION(XSM_OTHER);
> > +    if ( d->is_console )
> > +        return xsm_default_action(XSM_HOOK, d, NULL);
> 
> I will let Daniel commenting on this change. However ...
> 
> >   #ifdef CONFIG_VERBOSE_DEBUG
> >       if ( cmd == CONSOLEIO_write )
> >           return xsm_default_action(XSM_HOOK, d, NULL);
> > diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> > index 78bc326..2551e4e 100644
> > --- a/xen/xsm/flask/hooks.c
> > +++ b/xen/xsm/flask/hooks.c
> > @@ -443,7 +443,10 @@ static int flask_console_io(struct domain *d, int cmd)
> >           return avc_unknown_permission("console_io", cmd);
> >       }
> >   -    return domain_has_xen(d, perm);
> > +    if ( !d->is_console )
> > +        return domain_has_xen(d, perm);
> > +    else
> > +        return 0;
> 
> ... I don't think this change is correct. When a policy is used, the user is
> free to define what is the behavior. With your solution, you impose the
> console access even if the user didn't to not give the permission.

I was hoping Daniel would advise on the best way to do things here.

I thought that the idea was that granting a domain "is_console" is
equivalent to granting a domain XEN__READCONSOLE and XEN__WRITECONSOLE
permissions.  Thus, if is_console is set, we return 0 from
flask_console_io because the permissions check succeeds.

Given that I have accumulated many changes to this patch series, I'll
send out a new version now without making changes to this patch for now.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.