[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] One question about the hypercall to translate gfn to mfn.
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |