On Wed, Mar 04, 2009 at 10:11:41PM +0530, dinesh chandrasekaran wrote:
Hi dinesh
> Xen talks to the protection hardware behind which all the guest memory
> exists.
The memory is mapped.
And i was wrong, the dom0 can't just access all memory in the system.
> 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
So encrypt it in the Xen kernel.
> Since this guest.dump is encrypted by the protection hardware, and Xen
> just informed that "dom0 is running",
That assumes that the dom0 always has to run alone on the machine, in 2009 the
minimum server has 8 cores (next year 12) and often more.
> the encypted memory will only be released to dom0. This will be dumped
> into s file in dom0 disk.
Ok, so by taking a step back and looking at the problem again, i think
you are basically facing two possibilities:
1.) The security of the Xen kernel is brocken
-> You are lost, your hardware can't protect anything.
2.) The security of the Xen kernel is not brocke
-> Why on earth hardware? What you can do in Verilog on an FPGA, can
be done much more conveniently in C in the Xen kernel.
(Don't get me wrong, I'm all pro building hardware.)
Encypting in hardware gets interesting again when you want to try to protect
against physical attacks to the system. (assuming very good case intrusion
detection)
> > 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.
Well, solutions exist most likely in the form of IOMMUs.
Christian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home