dom0 vs non-dom0 differentiation inside Xen hypervisor

dom0 vs non-dom0 differentiation inside Xen hypervisor

[Peter Teoh]

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?

Re: dom0 vs non-dom0 differentiation inside Xen hypervisor

[Derek Murray]

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@lists.xensource.com
> http://lists.xensource.com/xen-devel

dom0 vs non-dom0 differentiation inside Xen hypervisor

[Peter Teoh]

[-- Attachment #1.1: Type: text/plain, Size: 825 bytes --]

 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.

[-- Attachment #1.2: Type: text/html, Size: 949 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: dom0 vs non-dom0 differentiation inside Xen hypervisor

[Ian Campbell]

On Mon, 2007-09-03 at 08:45 +0800, Peter Teoh 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?

No. The checks you are talking about are done using IS_PRIV() rather
than comparing directly domain==dom0.

e.g. from do_domctl and do_sysctl:
   if ( !IS_PRIV(current->domain) )
        return -EPERM;

In practise only dom0 passes this test.

Cheers,
Ian.

Re: dom0 vs non-dom0 differentiation inside Xen hypervisor

[Keir Fraser]

[-- Attachment #1.1: Type: text/plain, Size: 1225 bytes --]

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@gmail.com> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel



[-- Attachment #1.2: Type: text/html, Size: 1945 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel