Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.

[Tim Deegan <tim@xxxxxxx>]

Hi,

At 06:29 +0000 on 12 Dec (1418362182), Tian, Kevin wrote:
> If we can't containerize Dom0's behavior completely, I would think dom0
> and Xen actually in the same trust zone, so putting XenGT in Dom0 shouldn't
> make things worse.

Ah, but it does -- it's putting thousands of lines of code into that
trust zone and adding a new attack surface.  So it would be much
better if we could put XenGT in its own domain where it doesn't have
full dom0 privileges.

> However I'm not on whether XenGT must be put
> in a driver domain as a hard requirement. It's nice to have (and some
> implementation opens let's discuss in another thread)

Sure -- it would take a lot of toolstack work to actually put XenGT
into a driver domain.  So although I strongly encourage it, I don't
think it's a hard requirement.  But I'd like to make sure that we
end up with a XenGT that _could_ go in a driver domain if that
toolstack plumbing was done.  

> yep. Just curious, I thought stubdomain is not popularly used. typical
> case is to have qemu in dom0. is this still true? :-)

Some do and some don't. :)  High-security distros like Qubes and
XenClient do.  You can enable it in xl config files pretty easily.
IIRC the xapi toolstack doesn't use it, but XenServer uses privilege
separation to isolate the qemu processes in dom0.

> sorry write a long detail in this high level discussion. Just write-down
> when thinking whether this is practical, and hope it answers our concern
> here. :-)

Thank you for that, it's helpful to have a clear idea about it. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel