| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] dom0 vs non-dom0 differentiation inside Xen hypervisor
Hi Peter,
I think you'll find that all security-sensitive hypercalls contain a
test of IS_PRIV(current->domain), which is #defined in xen/include/
xen/sched.h. Only privileged domains are able to carry out operations
such as creating a domain, or accessing the memory of another domain.
In practice, dom0 is the only privileged domain (and, hence, it is
the only domain with its d->is_privileged bit set). However, it is
conceivable that another domain could be granted privileges, and so
we do not insist on the privileged domain being dom0.
Hope this helps.
Regards,
Derek Murray.
On 2 Sep 2007, at 08:12, Peter Teoh wrote:
In some parts of IA64 I can see that domain==dom0 checking is done,
but in all x86 - I have yet to find a proper checking that the
hypercalls comes from a dom0 domain instead of any other domain.
Theoretically, this means that any domain (PV or HVM) can always
modify its own kernel binary and then make a direct hypercall (via
int 0x82 or SYSENTER) into the hypervisor, executing domain
controller commands like create domain etc.
Is this possible? Access control should be done from the
hypervisor side, so any existing dom0 checking
(CONFIG_XEN_PRIVILEGED_GUEST compilation option - done from the
dom0 side) seems like useless, because another domU can always
modify its own kernel binaries to achieve all the features what
CONF_XEN_PRIVILEGED_GUEST restrict.
Am I right?
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home