From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Leber Subject: Re: Academic Project Date: Wed, 4 Mar 2009 09:45:58 +0100 Message-ID: <20090304084557.GA8743@core> References: <20090303225412.GA26841@core> <20090304005536.GA1450@core> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: dinesh chandrasekaran Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wed, Mar 04, 2009 at 08:25:49AM +0530, dinesh chandrasekaran wrote: Hi dinesh > > That implies the protection hardware is not controlled by the dom0 and > > there is another more secure way for the administration of it and second > > that the dom0 can't do anything. > > Absolutely. You are correct. Ok, so how do you plan to do this and why is this supposed to be more secure? > I guess the domain scheduling is done by the VMM and not by dom0? > Through VMM Hooks, the VMM is made to inform the device about the domain > scheduled to run. > So dom0 cannot claim to be any domU. I'm not really sure, but i think the dom0 can access the complete system memory. If not, then it controls at least some hardware that can do DMA and can this way access all the memory. -> dom0 can write/read all memory -> it can do anything > > furthermore the dom0 should also be able to overwrite the xen kernel. > > Can you throw some lights on the above "overwriting the xen kernel by > dom0"? A compromised dom0 could just replace the xen kernel/hypervisor on disk and/or in memory. Your idea just has so many problems, like what are you doing to do about disk i/o? Christian