| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] Academic Project
Christian,
Xen talks to the protection hardware behind which all the guest memory exists.
This is more secure because,
now if do the following you cannot extract any useful information
1) xm save Guest guest.dump (assuming a guest named "Guest" is already running)
this would dump the guest memory into a file in the dom0 disk.
2) Strings on guest.dump
Since this guest.dump is encrypted by the protection hardware, and Xen just informed that "dom0 is running",
the encypted memory will only be released to dom0. This will be dumped into s file in dom0 disk.
> If not, then it controls at least some hardware that can do DMA
> and can this way access all the memory.
You are correct. I will have to figure out a way in future to protect against such type of DMA attacks.
> A compromised dom0 could just replace the xen kernel/hypervisor on disk and/or in memory.
I think the secure boot using TPM would solve this issue of booting up a "replaced" xen kernel.
This project is just a prototype and I will have to work more to resolve all issues.
Thanks so much for your suggestions.
regards,
Dinesh C
> Date: Wed, 4 Mar 2009 09:45:58 +0100
> From: christian@xxxxxxxx
> To: dinesh_chan8@xxxxxxxxxxx
> Subject: Re: [Xen-devel] Academic Project
> CC: xen-devel@xxxxxxxxxxxxxxxxxxx
>
> 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
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
MSN Entertainment updates you on the latest blockbusters from Bollywood with MSN News.
|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home