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

Re: [Xen-devel] dom0 vs non-dom0 differentiation inside Xen hypervisor


  • To: Peter Teoh <htmldeveloper@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
  • Date: Mon, 03 Sep 2007 14:42:30 +0100
  • Delivery-date: Mon, 03 Sep 2007 06:43:22 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfuMEXJhD85FVojEdyxegAX8io7RQ==
  • Thread-topic: [Xen-devel] dom0 vs non-dom0 differentiation inside Xen hypervisor

Privileged hypercalls are all protected by IS_PRIV() checks on the current domain.

See common/sysctl.c and common/domctl.c, for example.

 -- Keir


On 3/9/07 01:45, "Peter Teoh" <htmldeveloper@xxxxxxxxx> wrote:

In some parts of IA64 I can see that domain==dom0 checking is done, but in all of 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 pointless, because another domU can always modify its own kernel binaries to achieve all the features what CONFIG_XEN_PRIVILEGED_GUEST restrict - be it Windows XP or Linux.

Please enlighten us.


_______________________________________________
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

 


Rackspace

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