Xen devel - Feb 2004 - Re: Questions about the control tools in Xen

In the Xenolinux source code, I found that in function of
HYPERVISOR_dom0_op, it would set the interface version to
DOM0_INTERFACE_VERSION!!
Does Xen VMM check the commands come from domain0 or not just acording with
the interface version?
If another domain boot by the xenolinux kernel as same as domain 0 and use
the privileged tools, can this domain create or delete another domains?
Another question:
How guest OS set into kernel mode from ring 3 into ring 1 insteed of ring 3
into ring 0

Thanks a lot !!

Cheers,

Inaba
> > > Recently, I have traced part of the Xen VMM code.
> > >
> > > but I have some troubles...
> > >
> > > I could not find out the function ioctl() which is called by the
> function do_privcmd() (xeno-1.2.bk/tools/xc/lib/xc_private.h)
> >
> > "man ioctl" -- its a system call
>
> I got it , thanks a lot !!!
>
> >
> > > Is the interface between guest OS and VMM just like the interface
> between OS and Hardware ?
> >
> > Similar, but different. The best overview description is in the
> > SOSP paper available off the project web page.
>
> I''m reading this paper now, but I could not understand how guest
OS set
into
> kernel mode from ring 3 into ring 1 insteed of ring 3 into ring 0.
>
> which functions or codes need to be modified in Xenolinux source code?
>
> >
> > > Is there any protection in Xen VMM to protect that only Domain 0
could
> use the control tools?
> >
> > Yes. There''s a concept of a ''privileged
domain'' that all dom0_ops
> > and other hypervisor interfaces check. In future, we may allow
> > delegations to enable, for example, domain 3 to be able to
> > control and manipulate domain 7 but no others.
>
> I''m not really understand the concept ''privileged
domain''  means.
>
> but I have traced some of codes in xen.
>
> I found that pyxc_domain_create() would call the function
> xc_domain_create() -> do_dom0_op() -> do_xen_hypercall() ->
do_privcmd() ->
> ioctl()
>
> In xc_domain_create() would fill in some parameters into dom0_op_t data
> structure.
>
> But if another domain such as domain 1 calls the function
> pyxc_domain_create(), then it would create another domain ??
>
> I guess that in Xen VMM it would check the the request of operations comes
> from which domain. (domain number or address space ???)
>
> If I want to know the protection mechanism which function I need to trace
?
>
> Cheers,
>
> Inaba
>
> >
> > Best,
> > Ian
> >
>




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> In the Xenolinux source code, I found that in function of
> HYPERVISOR_dom0_op, it would set the interface version to
> DOM0_INTERFACE_VERSION!!
> Does Xen VMM check the commands come from domain0 or not just acording with
> the interface version?
DOM0_INTERFACE_VERSION is #defined in xen/include/hypervisor-ifs/dom0_ops.h 
(which holds various details about the valid dom0 ops and their data 
structures).  The idea is that whenever there is a change to the interface, 
the interface version number will be changed.  This way, if you''re
using a set
of control tools that were built for an older version of the interface, Xen 
will see that the version is different (the check for this is in 
xen/common/dom0_ops.c::do_dom0_op() ).  This is to prevent people using 
control tools that are built with the wrong interface.
> If another domain boot by the xenolinux kernel as same as domain 0 and use
> the privileged tools, can this domain create or delete another domains?
The xenolinux kernel normally used by dom0 includes a control interface for 
sending commands to Xen from the control tools.  The interface consists of 
some files under /proc/xeno/ - you''ve probably already seen some of the
code
related to this.

If you boot other domains using this kernel then they will also have those 
special files BUT they *won''t* be able to use them to do privileged
control
ops *unless* they are made privileged.  By default, other domains are not made 
privileged, so usually the control interface in /proc/xeno won''t do
anything
in non-0 domains.  If you want you can build a different kernel for your 
non-privileged domains, removing the control interface in the kernel config.

When domains attempt to perform privileged operations, Xen checks that they 
are really allowed to do them (i.e. that they are privileged).  You can see 
one such check at the start of xen/commond/dom0_ops.c::do_dom0_op() - Xen 
returns an EPERM error if the domain is not privileged.

Well, that''s the detail.  But in summary: only privileged domains can
access
the Xen control interface.  Domains (other than 0) are unprivileged by 
default.  The /proc/xeno interface only works on privileged domains, on others 
it won''t do anything.

HTH.

Mark



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel